Вам, наверное, не бд нужна, а full text search engine или даже самописный продукт. Выбор СУБД будет зависеть от поддерживаемых хранилищ.

Некоторые СУБД имеют свой FTS, в таком случае лучще смотреть на PG из всего списка.

C регэкспами губу скорее вссего придётся закатать заранее.

> Некоторые СУБД имеют свой FTS

sqlite в том числе

Сфинкс, ксапиан

Если не путаю названия

Для talks; передвинул.

Плюсую sphinx. Работает очень быстро на больших объемах данных.
А базу я бы взял постгрес, но это собственно не так важно.

Или это вопрос не для Talks?

Задавай вопрос в Talks, будь готов получить ответ в стиле Talks.

Та, которую умеешь правильно настраивать/с которой опыта работы больше.

Если записей будет от 1.000.000+, то я бы посоветовал postgresql.

// Кодировку uft8 в записях не используй. Зае*шся с сюрпризами.

Вариант1 - обычные индексы БД. Ускоряют только поиск полностью совпадающей строки (или подстроки в начале строки) - подобно алфавитному поиску в словаре. И такие индексы рассчитаны на относительно короткие строки (условно - до 256 байт). Если твоя задача вписывается в такие ограничения, то тебя устроит любая БД - поиск по индексу в БД очень быстрый.

Вариант 2 - Полнотекстовый поиск. Ищет тексты содержащие указанные слова (порядок слов в тексте может отличатся от порядка слов в строке поиска - собственно на этот режим и заточены алгоритмы полнотекстовой индексации). Пример - http://sphinxsearch.com/. Полнотекстовые индексы реализованы и в MySQL и в Postgresql, хотя и не так эффективно.

Если все тексты по которым ведется поиск влезают в файловый кеш, или обязательно нужен поиск по регуляркам, то тебя вполне устроит -

Вариант 3 - полный перебор. На однопользовательской машине скорость поиска будет ограничена скоростью чтения с диска. Либо хранить все в файле собственного формата, либо в БД. Все БД поддерживают поиск полным перебором. Кстати, это (полный перебор) - единственный вариант, когда можно использовать регулярные выражения. Если нужно структурирование, хранение доп. данных и обновление/удаление - можно хранить все в БД. В Postgresql есть поиск текста по регулярному выражению.

> Задавай вопрос в Talks, будь готов получить ответ в стиле Talks.

Вообще-то я его задал в Development. Но Casus решил иначе.

Столько комментариев, а на заданный вопрос — об объёме — ответил всего один. И то не полностью.

> Сфинкс, ксапиан

При каком объёме базы это не будет стрельбой из пушки по воробьям?

> Если записей будет от 1.000.000+, то я бы посоветовал postgresql.

Спасибо. Первый количественный ответ в теме :)

А если их будет на порядок меньше?

Кодировку uft8 в записях не используй. Замучаешся с сюрпризами.

Догадываюсь :) Опыт есть. А как насчёт wchar_t[]? Я так понимаю, это — UCS-4 и UTF-32.

> Вариант1 - обычные индексы БД. Ускоряют только поиск полностью совпадающей строки (или подстроки в начале

Годится. Таблиц транслитерации немного, можно добавить в каждую запись по преобразованной строке для каждой таблицы.

такие индексы рассчитаны на относительно короткие строки (условно - до 256 байт).

Байт или символов? Хотя тут и 64 символов более чем достаточно.

С какими базами можно использовать «широкие» символы (тип wchar_t)?

Вариант 2 - Полнотекстовый поиск ... порядок слов в тексте может отличатся ... на этот режим и заточены

Этого не нужно.

Вариант 3 - полный перебор. ... единственный вариант, когда можно использовать регулярные выражения.

Я так понимаю, он — самый медленный? Обидно.

Если нужно структурирование, хранение доп. данных

Нужно.

можно хранить все в БД. В Postgresql есть поиск текста по регулярному выражению.

Спасибо за подробные объяснения.

> Вам, наверное, не бд нужна, а full text search engine

При какой длине строк он приобретает преимущество?

или даже самописный продукт

Строго наоборот :) Надоело блуждать в нагромождениях арифметики указателей.

Некоторые СУБД имеют свой FTS, в таком случае лучще смотреть на PG из всего списка.

Спасибо, учту.

C регэкспами губу скорее вссего придётся закатать заранее.

Как насчёт транслитераций?

Думаю не будет. API у них более удобные для этого