Как сделать поиск по базе mysql?

[pavel012007]

А где видно, что я это отрицаю?

Вы не отрицаете - Вы не отвечаете на вопрос. Ваш ответ "Я утверждаю, что полнотекстовый поиск ищет лучше" - это не ответ на вопрос "Вы отрицаете, что MATCH-AGAINST больше грузит мускул по сравнению с LIKE?". Я не прав?

"Вот и воздерживайся" - Какое же это хамство?
Это пожелание следовать собственным словам

Фразой "Я бы воздержался от комментариев, "изврат" это или "не изврат" вам намекнули, что "изврат" - тоже хамство (если вы этого не понимаете). Поскольку это ваше лично мнение, причем выраженное в грубоватой, мягко говоря форме. А что оно личное - если оно личное, из реплики непонятно - вы даже не указываете. Получается - вешаете ярлык, хамите.

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

 

[PHP_Master]

Ваш ответ "Я утверждаю, что полнотекстовый поиск ищет лучше" - это не ответ на вопрос "Вы отрицаете, что MATCH-AGAINST больше грузит мускул по сравнению с LIKE?". Я не прав?

Мне сам вопрос непонятен, я ничего не отрицал.
Скажу по другому, если с первого раза не получилось доходчиво - на заданный вопрос не будет однозначного ответа. При одних условиях полнотекстовый поиск будет медленне, при других быстрее.

А получать от вас регулярное "ты" в ответ на "вы" не может быть "привычной формой общения на этом форуме".

Так не общайТЕСЬ со мной. Какие проблемы?
А коль уж так рдеете за культуру общения, то неплохо бы было знать, что "вы" при персональном обращении к одному лицу принято писать с большой буквы.

 

[pavel012007]

...
А для поиска по тексту ничего лучше полнотекстового поиска ещё не придумали (это и составные поисковые запросы и релевантность, а не тупое попадание в ведённый текст).

При использовании поиска через LIKE какая то релевантность тоже требуется - вывод надо же как-то упорядочивать, от более совпадающих фраз к менее совпадающих с поисковой фразой. В простых случаях поиска и не очень большого количества записей, которое кстати полнотекст не "берет", реализация упорядочивания элементарна и проще того что заделано в полнотекстовом поиске. А значит и работать будет шустрее.

 

[PHP_Master]

Какая релевантность, какие "более совпадающих фраз" и "менее совпадающих" у LIKE, если тупо ищется точное совпадение по маске?

 

[pavel012007]

Какая релевантность, какие "более совпадающих фраз" и "менее совпадающих" у LIKE, если тупо ищется точное совпадение по маске?

Еще раз обращаю ваше внимание, что в данный момент речь ведется не о LIKE, а о способе упорядочения вывода, отобранного при помощи LIKE. Ведь то, что нашлось по LIKE, прописываемому во WHERE, нужно выдать для просмотра в каком то порядке. А он и должен быть в каком то смысле "релевантным", т.е. строки "более соответствующие" должны выдаваться раньше (выше) "менее соответствующих". В простых случаях, типа этого, делается такой "релевантный" вывод элементарно.

 

[PHP_Master]

Еще раз обращаю ваше внимание, что в данный момент речь ведется не о LIKE, а о способе упорядочения вывода, отобранного при помощи LIKE. Ведь то, что нашлось по LIKE, прописываемому во WHERE, нужно выдать для просмотра в каком то порядке. А он и должен быть в каком то смысле "релевантным", т.е. строки "более соответствующие" должны выдаваться раньше (выше) "менее соответствующих". В простых случаях, типа этого, делается такой "релевантный" вывод элементарно.

SQL - не поисковая система, которая формирует выдачу релевантно.
Нет в SQL понятия более соответствующий или менее соответствующий. При выборке LIKE (да и любой другой) все результаты равнозначны, выборка сортируется в порядке нахождения записей либо по заданному правилу (ORDER|GROUP BY).

Автоматическая сортировка по релевантности присутствует только в одном варианте выборки - полнотекстовом поиске.

 

[Alternator]

выскажусь я по поводу FULLTEXT и LIKE
первый требует больше ресурсов под свои индексы.
второй очень сильно грузит проц и винт, так как поднимает все чравниваемые строки из БД.
когда мне надо было органзовать поиск по базе размером в 5милионов записей, я очень удивился когда LIKE сработал за 3 секунды.я искренне полагал, что будет медленнее.
но, потому я посмотрел, что во время процесса, мускул успевает поднять всю базу с винта, и обработать(нагрузка на проц -100%.винт также немалая), я понял, что это не то.
FULLTEXT же пробегал у меня эту таблицу менее чем за сотую секунды.
НО, к сожалению находил примерно две трети строк из тестового запроса.
в моей задаче требовался не релевантный поиск со всякими морфологическими фичами, а бинарный поиск по произвольной подстроке, поэтому мне FULLTEXT также не подходил.
в итоге пришел к выводу необходимости использования доп-таблицы индексирующей подстроки в основной.
результат -примерно 0,3 секунды на нахождение любой подстроки в базе
средняя длина строки в базе - 17символов(это были имена файлов)

я тут написал много воды, вот резюме для ТС-а:

при использовании поиска LIKE, хостер может вас попросить уйти, из-за большой нагрузки на проц и винт
поэтому лучше используйте FULLTEXT
также для морфологического анализа(в MySQL для русского пока еще все довольно плохо) почитайте эту статью и ее сопровождающие:
Для просмотра ссылки Войди или Зарегистрируйся

2 pavel012007 - вот, я точно считаю, что %LIKE% медленне и более нагружен, чем FULLTEXT , для большинства задач. И я слабо себе предстваляю реальную таблицу, где бы лучше был %LIKE%

 

[pavel012007]

SQL - не поисковая система, которая формирует выдачу релевантно.
Нет в SQL понятия более соответствующий или менее соответствующий. При выборке LIKE (да и любой другой) все результаты равнозначны, выборка сортируется в порядке нахождения записей либо по заданному правилу (ORDER|GROUP BY).

Автоматическая сортировка по релевантности присутствует только в одном варианте выборки - полнотекстовом поиске.

Задача сформировать выдачу "релевантно" - задача и разработчика СУБД. И понятия "более соотвествующий или менее соответствующий" легко реализуются, это тоже может реализовать разработчик СУБД. Что, с помощью LIKE и ORDER BY трудно сделать "релевантную" выдачу для поиска по фразе "ремонт машин"? Ясно что наверх должны попасть записи где есть слова "ремонт" и "машин" как более релевантные. За ними содержащие только одно слово - "ремонт" (часов, например). Или (покраска) машин.

to Alternator согласен, если используются большие базы как у Вас - несколько миллионов записей. Но для простых таблиц типа телефонного справочника и LIKE прокатит. А какой размер индекса получился для полнотекстового поиска для 5000К базы, если не секрет? Это ведь тоже критерий - LIKE или полнотекст

 

[Alternator]

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

Таблица `files`:
4,640,250 записей. 435.8 MB
Таблица `filename_index`:
71,496,863 записей. 2.3 GB

в первой-собственно данные.
во второй - все наборы подстрок длиной 4 символа из первой таблицы.
для поиска по подстроке, она урезается до 4-х символов, и ищется во второй по индексу
размеры таблиц вместе со всеми индексами указаны, поэтому сказать сколько какой индекс у меня весит трудно.
по моему первая таблица на момент этого замера не содержала в себе FULLTEXT-индекса
более подробно о моих экмериментах по поиску подстроки в именах файлов, можете посмотреть Для просмотра ссылки Войди или Зарегистрируйся
иной инфы у меня пока под рукой нету, а возобновлять проект пока не собираюсь

 

[maxdam]

может сначала разбить искомые слова с запроса и потом вывести по этим словам с сортировкой?