Правильный поиск по базе - каков он?

какой-то аноним считает, что sphinx плохо работает, но боится это сказать?

Когда-то реализовывал поиск по базе автозапчастей по нечёткому вхождению артикула:

$parts_ids = implode(", ", $parts_temp);



$parts_query_det="

SELECT

    ART_ARTICLE_NR,

    SUP_BRAND,

FROM

    ARTICLES

WHERE

    ART_ID IN (".$parts_ids.")";

	

$parts_det_select=$db->query($parts_query_det);

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

Гемморойно, поэтому если задача позволяет - пользуйтесь LIKE и не мучайтесь. А если нужно что-то более скоростное - тогда придется долго страдать над кодом. :)

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

в некоторых случаях. допустим, если поиск происходит в небольшом словарике из 100 строк, который никогда не растет во время эксплуатации сайта.

Можно использовать phpmorphy для автоматического создания поискового индекса. Алгоритм примерно такой:

1. базу материалов вяжем с базой индексов этих материалов где каждое слово приведено в инфинитив (библиотекой же) и скажем к верхнему регистру, убраны стоп слова и любые небуквенные знаки.

2. получаем поисковый запрос - приводим в инфинитив.

3. ищем прямым совпадением по поисковому индексу.

Я такой поиск реализовал у себя на сайте. Из плюсов то, что запрос получается морфологически независимым а поиск происходит достаточно быстро. По таблице содеражещей свыше 100000 вхождений запрос из четырех слов ищет меньше секунды.

Решил я использовать Fulltext, а там непонятное что-то. Ищет быстро, но не все находит

Например, в БД есть записи, содержащие поисковую фразу, например "ах":

Но фуллтекст их не видит. Запрос простой

Вопрос - насколько большая база?

Если вдс/сервер свой, то самый простой вариант, это держать базу текстов тупо в памяти. Самое простое в memory table. Искать лайком, индексы не вешать. Даже в жалкие (по нынешним временам) 512 мегабайт влезает 256 тысяч описаний фильмов с хорошим запасом, например (особенно если побить длинные описания на разные строки). Зато вопрос со скоростью поиска решается кардинально и главное - легко. Тупой прямой подход иногда рулит:)

p.s.: Естественно в memory table только дубли для поиска, т.к. мало ли сервер вырубится:) Если длина текста сильно разная, то в связи с тем, что в memory table можно использовать поля только фикс.длины, есть смысл сделать допустим поле в 4кб, если тексты превышают 4кб, то бить на несколько строк - сэкономите чутка памяти. И это, не забудьте - если только русский язык, используйте внутри БД для хранения cp1251 вместо utf8, по памяти и скорости выиграете изрядно.

Поскольку like '%ах%' индексов не использует, то это в любом случае raw поиск. И тут разница будет между 512Мб диска и 512Мб памяти, а это таки разница. Альтернативные варианты хотя и красивее, по скорости это памятежрущее решение вряд ли побьют.

Есть вариант просто хранить таблицу MyISAM на "временном" диске в памяти, но это более сложное решение, требующее вмешательства админа в том числе.

Тут в соседнем топике о хетзнере спрашивали куда можно 32Гб на одноядерном сервере потратить - дык вот, на поиск, можно и больше:)

Таблица содержит 34.000 записей весом около 300 мб.

Пошел читать про memory table

в настройках по умолчанию минимальное индексируемое слово - 4 буквы.

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

перебор по 512 мб в памяти не такой уж и быстрый. не самая хорошая идея.