Столкнулся с проблемой поиска в базе данных MySQL.
SELECT `id` FROM `db_name`.`words` WHERE `word` LIKE 'ПОИСКОВЫЙ_ЗАПРОС'
меня совсем не устраивает.

Пусть в базе данных хранятся тексты. Например «Привет медвед! Как твои дела?».
Пользователь вводит в строку поиска слово «медвед», в базу данных отправляется запрос:
SELECT `id` FROM `db_name`.`words` WHERE `word` LIKE '%медвед%' .
База данных возвращает нам необходимое значение.

А если человек введет слово «медвед» с ошибкой, например «мидвед» или «меддвед» или «мевед» или вообще введет «МеДвЕд», то в базе данных ничего найдено не будет. 

Решение я придумал такое. При помощи цикла составлять такие вот запросы: 



Т.е. искать при помощи регулярных выражений, учитывая все возможные ошибки.

Но такой метод, как мне кажется, будет очень долгим и ресурсоемким. 
Как бы вы организовали поиск по базе данных, с учетом возможных ошибок и очепяток пользователя? 

 




Это сообщение отредактировал(а) NLspieler - 8.3.2009, 18:16

NLspieler, а sounex для кирилицы еще не сделали?

Я впервые слышу про sounex.
Что это такое? И как его использовать для текущей задачи?

soundex

в цикле формировать маски - да, это отстой.
тебе надо разложить задачу на составляющие.
отдельно решить вопрос индексирования текста, то есть создание связи "текст" <-> "множество ключевых слов". 
отдельно решать вопрос поиска. т.е. вместо работы с исходным текстом, ты проводишь сравнение со связанными с ним ключевыми словами.
и вот тут уже вариантов хватает:
1. прямое сравнение(с учетом регистра и без)
2. soundex - "поиск по звучанию"
3. поиск по словарю(чтоб проходило сравнение "быстро" == "мгновенно" или "CPU" == "процессор" )
4. стемминг("радостный" == "радости")
5. собственный алгоритм.

а че, для кирилицы разве есть реализация soundex в mysql? или идем по пути "кирилица" -> "translit" -> "soundex"?

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

В 

как-то слабо верится. А что, работает?

да, но коряво, само собой.
soundex "может работать некорректно с кодировкой utf8" и "для слов из символов не английского язіка может возвращать неадекватные значения".
есть "попытки создания soundex для русского языка"(как указано в википедии), но насколько удачные - не знаю. впрочем, редкий хостинг позволит установить библиотеку с MySQL UDF.

Посмотрел страницу о sounex в википедии.
Нашел там ссылку на неплохой sounex для кириллицы, на php.

Очевидно, что это то, что мне нужно!
Например, слова 
'аренсфелде' и 'ариентсвелде' пропущенные через эту функцию выдают одинаковый результат А652.
А строка 'ориенсфэлдэ' выдает О652.
По-моему, это просто гениально!!!


Значит в MySQL таблицу нужно добавить дополнительное поле индекс, в котором хранить sounex - индексы, 
слов соответствующего текста
 и производить поиск уже по ним.  


Это сообщение отредактировал(а) NLspieler - 9.3.2009, 11:41

soundex!

Искать надо то, что пользователь сказал искать.
Пользователь не обрадуется. если при вводе "медвед" ему выдадут варианты с "медведь".

И лишь отдельно надо ПРЕДЛОЖИТЬ поискать по исправленному варианту.

Ну вот. Теперь я опять запутался. 

Значит для поиска по «неисправленному тексту» нужно дополнительное поле индекс, в котором хранить текст без лишних символов, в одном регистре (все буквы либо маленькие, либо все буквы большие).
Или же можно производить поиск по базе, не зависимо от регистра букв?
Т.е. как сделать, что бы запрос «привет» выдавал результаты «ПрИвеТ», «Привет», «ПРивет» или «привет» ?   
 

в зависимости от заданного collation. если там utf8_general_cs - то поиск будет регистрозависимым, если utf_general_ci - регистронезависимым.

Кодировка предположительно будет такой cp1251_bin

 Зачем? о_О

А почему бы и нет?

Вообще, я до сих пор парюсь с кодировками. 
Когда я увидел список кодировок в MySQL, голова пошла кругом. 
Методом простого перебора, нашел первую попавшуюся, с которой все нормально работало, и это оказалась cp1251_bin

Ну по кодировкам стоит лезть в инет и отдельно читать... если cp1251 - лучше всего cp1251_general_ci - регистронезависимая, а еще лучше юзать UTF8 по определению... мало ли какие случае будут у Вас на сайте... вдруг придется какие-то языки экзотические постить ?

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

 Естественно. Используй одну везде.
Это utf-8.
Иначе затра... замучаешься с перекодировками.

Поставил в базу данных utf8_general_ci
Но на сайте, всеравно приходится ставить windows-1251, иначе получаються кракозябры. 

Вот я и не знаю, в чем и где ошибка. 

Это сообщение отредактировал(а) NLspieler - 9.3.2009, 22:52

мдя... может немного стоит почитать - поэкспериментировать самому ? тебе надо добиться чтобы сайт был в utf8

Все экспериментальные силы исчерпались. 
Читать не знаю о чем и где.

а что конкретно неправильно отображается ?

Добавлено через 1 минуту и 1 секунду
то что ты тянешь с базы ?

http://test.test123.tu2.ru/nggg.php

Вот тестилка.
В форму писать запрос: %ПР%

Сейчас кодировка windows-1251 и все нормально работает. 
Если же поставить кодировку utf-8, то тогда запрос возвращает пустое значение. Короче, ничего не находит.

Если же производить поиск с кодировкой windows-1251, а потом изменить ее на utf-8,то русские буквы превращаются в вопросики.


Такое ощущение, что перед входом в базу данных, запрос превращается из windows-1251 в utf-8
А выходящие данные наоборот превращаются из utf-8 в windows-1251.  
Но я ни о чем таком нигде не писал, таких приказаний не давал.

попробуй так...=\

Теперь все впорядке   

А ведь пробовал же ставить так:
SET CHARACTER SET utf8_general_ci
конечно же, безрезультатно.

Ларчик, как говорится, просто открывался.