Я думал об этом и пытался найти решения о том, как нечеткий поиск в базе данных, если, например, пользователь вводит орфографическую ошибку. Есть какие-то явные проблемы с логикой этого? Будет ли это работать и было ли это сделано раньше?
Наш стол мы хотим найти:
**tblArticles**
Body - Soundex_Body - CharacterCoded_Body
Поэтому мы храним необработанное текстовое тело для физического отображения. Другие 2 столбца используются для поиска, который рассчитывается следующим образом:
Саундэкс
Тело разделено на слова и переведено в версию soundex. IE, получающееся тело могло бы быть чем-то вроде:
H252 B54 C23 E33... etc
Таким образом, кто-то может войти в «динозавр», а текст статьи гласит «динозавр», оба они оценивают как B26. Затем мы запускаем LIKE для значения soundex поискового термина.
Кодировка персонажа
Учитывая отображение символов, которое отображает символы в простые числа, IE:
h = 2
e = 3
l = 5
o = 7
p = 11
c = 13
help = 2*3*5*11 = 330
hello = 2*3*5*5*7 = 1050
hell = 2*3*5*5 = 150
hlep = 2*5*3*11 = 330
cello = 13*3*5*5*7 = 6825
Если пользователь хотел напечатать «привет», но он переключил два или более символов, например, «hlelo», он оценил бы одно и то же число. Разделите необработанное тело на слова, просто закодируйте каждое слово и сохраните в базе данных, получив поле, которое выглядит следующим образом:
330 6825 330 1050... etc
Затем мы можем подобрать поиск по этому значению, чтобы он соответствовал опечаткам.
Преимущества
- Опечатки защищены от
- Фонетическое неверное написание защищено от
- Больше не родной английский говорящий дружелюбный
- Будет работать на любом языке (где работает soundex)
Комментарии и мысли? Этакий многослойный поиск. Конечно, вы можете взвесить возвращаемые значения, чтобы сделать его еще лучше (например, буквальное совпадение текста стоит больше), но действительно ли это хорошее решение для орфографических ошибок и поиска не носителями английского языка?
Ответы:
Есть ряд других алгоритмов поиска. Смит-Уотерман - один из лучших для человеческого текста, в то время как BLAST (пока) - лучший для поиска последовательностей ДНК. Когда вам представлен текст с различными орфографическими ошибками, такими как
hlepвместоhelp, то вы ищете минимальное расстояние редактирования .Для библиотеки для реализации ряда этих функций в CLR в SQL Server 2005 (и более поздних версиях) посмотрите исходный проект forge подделки SimMetrics . Сообщение в блоге о SimMetrics .
http://staffwww.dcs.shef.ac.uk/people/S.Chapman/simmetrics.html
Soundex был разработан потому, что основные различия между региональными речевыми вариациями были почти исключительно в гласных - именно поэтому он выбрасывает гласные. Не очень хорошо справляться с транспонированными буквами.
источник
Apache Solr, поддерживает синонимы и исправления орфографии - хотя это все еще немного грубо по краям.
Нечеткие поиски могут быть реализованы с помощью Ngrams,
Портер Стеммер: http://tartarus.org/~martin/PorterStemmer/
и языковая база данных, такая как http://wordnet.princeton.edu/
... но такие проекты, как Xapian и Solr, справятся с этим.
Если вы хотите создать свой собственный механизм анализа / поиска по поисковым словам, я бы предложил поместить сгенерированные вами токены или термины в существующую базу данных, предназначенную для поиска по языку.
источник
Некоторое время назад я делал что-то подобное для адресов, которые проверяли бы, сколько изменений потребуется, чтобы преобразовать одну строку в другую, и возвращали числовое значение в диапазоне от 0 до 1, чтобы определить, насколько близко они совпадают.
Это сработало замечательно, поскольку возвращало большое значение для таких элементов, как N / North, St / Street, EastMain / MainEast и т. Д. Идея пришла из этой ссылки CodeProject.
источник
Если вы сопоставляете имена, людей или места, список синонимов может работать намного лучше.
Soundex не будет соответствовать "Дик == Ричард", "Кит == Кристофер" или "Мисс. == Миссис".
источник