Варианты имени в базе данных - PullRequest
10 голосов
/ 22 февраля 2009

Я пытаюсь определить, как лучше всего найти вариации имени в базе данных. Например, я ищу Билла Смита. Я хотел бы, чтобы он возвратил «Билла Смита», очевидно, но я также хотел бы, чтобы он возвратил «Уильяма Смита», или «Билли Смита», или даже «Вилли Смита». Моей первоначальной мыслью было построить иерархию имен, но я не знаю, где я мог бы получить такие данные, если они вообще существуют.

Поскольку пользователи могут искать в каталоге, я подумал, что это будет ключевой особенностью. Например, люди, с которыми я ходил в школу, называли меня Джо, но теперь я всегда иду рядом с Джозефом. Итак, я собирался провести фонетический поиск по фамилии, либо с помощью NYSIIS, либо с Double Metaphone, а затем выполнить поиск по имени, используя это имя heirarchy. Есть ли лучший способ сделать это - может быть, какая-то ступенчатая релевантность с использованием полнотекстового поиска по полному имени вместо поиска по двум частям по имени и фамилии? Часть меня считает, что если бы я хранил имя как одно значение вместо нескольких значений, это могло бы облегчить поиск дополнительных параметров за счет возможности обратиться к пользователю по имени.

Что касается платформы, я использую SQL Server 2005 - однако у меня нет проблем с переносом некоторых соответствий в код; например, предварительная посылка фонетических клавиш для пользователя, поскольку они не изменятся.

Будем благодарны за любые мысли или советы. Бесчисленные поиски оказались почти пустыми. Спасибо!

Редактировать: Кажется, что по функциональности есть два очень разных лагеря, и я определенно сейчас сижу посередине. Я мог видеть аргумент полнотекстового поиска - скорее всего, из-за отсутствия нормализации данных и подхода, состоящего из нескольких частей, который использует разные критерии для разных частей имени.

Проблема в конечном итоге сводится к намерению пользователя. Пример Билла / Уильяма хорош, потому что он показывает мутацию имени, основанную на формальности использования. Я думаю, что построение иерархии имен является более точным (и расширяемым) решением, но будет гораздо более сложным. Подход нечеткого поиска легче реализовать за счет точности. Это справедливое сравнение?

Решение. После некоторых тестов я решил использовать подход, при котором первоначальная регистрация будет иметь полное имя, и я разделю его на несколько полей (имя, фамилия, отчество, суффикс и т. Д.). ). Поскольку я уверен, что это не будет идеально, я позволю пользователю редактировать «части», включая добавление девичьей или альтернативной фамилии. Что касается поиска, то в любом решении мне нужно будет указать, какие варианты существуют, либо в таблице базы данных, либо в виде тезауруса. Ни один из них не имеет преимущества перед другим в этом случае. Я думаю, что это будет сводиться к производительности, и мне придется на самом деле запустить некоторые тесты, чтобы определить, что лучше. Спасибо всем за ваш вклад!

Ответы [ 9 ]

3 голосов
/ 22 февраля 2009

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

В случае человеческих имен, компьютер будет ошибаться большую часть времени, сделать это правильно и полностью невозможно, ИМХО. Может быть, вы можете взломать что-то, что делает наиболее распространенные английские имена. Но на самом деле интеллект для поиска «Билла» и «Уильяма» встроен практически в любого говорящего по-английски человека - я бы оставил им возможность соединить точки.

1 голос
/ 07 января 2014

Вы ищете термин «гипокоризм»:

http://en.wikipedia.org/wiki/Hypocorism

И Википедия перечисляет многие из них. Вы можете использовать Python или Perl, чтобы очистить эту страницу и поместить ее в БД.

Я бы пошел с такой структурой:

create table given_names (
  id int primary key,
  name text not null unique
);

create table hypocorisms (
  id int references given_names(id),
  name text not null,

  primary key (id, name)
);

insert into given_names values (1, 'William');
insert into hypocorisms values (1, 'Bill');
insert into hypocorisms values (1, 'Billy');

Тогда вы можете написать функцию / sproc для нормализации имени:

normalize_given_name('Bill'); --returns William

Одна проблема, с которой вы столкнетесь, заключается в том, что разные имена могут иметь одинаковый гипокоризм (Альберт -> Ал, Алан -> Ал)

1 голос
/ 13 марта 2009

Вы обнаружите, что балуетесь областью, известной как «Обработка естественного языка», и вам нужно будет сделать несколько вещей, большинство из которых можно найти в теме stemming .

Упрощенный ствол просто разбивает слово на части, но более продвинутые алгоритмы связывают слова, которые означают одно и то же - например, Google может использовать ствол для преобразования «кошка» и «котенок» в «кошачье» и искать все три, взвешивая фактическое слово, предоставленное пользователем, немного тяжелее, поэтому точные совпадения возвращаются до сопоставления с основанием.

Это известная проблема, и существует доступных исходных кодов .

-Adam

1 голос
/ 22 февраля 2009

Не уверен, что ваше приложение, но если ваши пользователи знают во время регистрации, что люди из их прошлого могут искать их в базе данных, вы можете предложить им возможность в профиле пользователя определить другие имена, которые они могут быть известным как (включая фамилии, женщины все время меняют их и делает поиск их намного сложнее!) и что они хотят, чтобы люди могли искать. Храните их в отдельной связанной таблице. Тогда ищи на этом. Просто сделайте структуру такой, чтобы вы могли определить одно имя как основное (то, которое вы используете для всего, кроме поиска).

1 голос
/ 22 февраля 2009

Вы можете использовать полнотекстовый поиск SQL Server и выполнять инфлекционный поиск.

В основном, как:

ВЫБЕРИТЕ ProductId, ProductName FROM ProductModel ГДЕ СОДЕРЖИТСЯ (Каталожное описание, «ФОРМА (ТЕЗАУРУС, МЕТАЛЛ)»)

Выезд: http://en.wikipedia.org/wiki/SQL_Server_Full_Text_Search#Inflectional_Searches http://msdn.microsoft.com/en-us/library/ms345119.aspx http://www.mssqltips.com/tip.asp?tip=1491

1 голос
/ 22 февраля 2009

Используете ли вы SQl Server 2005 Express с расширенными службами, как мне кажется, вы получили бы пользу от полнотекстовой индексации и, в частности, от Contains и Containstable, которые вы можете использовать с конкретными инструкциями. Вот ссылка для использования Containstable: 1001 *

http://msdn.microsoft.com/en-us/library/ms189760.aspx

и вот ссылка для загрузки SQL Server 2005 с расширенными службами:

http://www.microsoft.com/downloads/details.aspx?familyid=4C6BA9FD-319A-4887-BC75-3B02B5E48A40&displaylang=en

Надеюсь, это поможет,

Andrew

1 голос
/ 22 февраля 2009

Я думаю, что ваш основной подход является надежным. Я не думаю, что полный текст поможет вам. Что касается заполнения, то на сайтеthenthename.com, по-видимому, содержится большой объем нужных вам данных.

0 голосов
/ 13 марта 2009

Вот идея для автоматического поиска «синонимов имени», таких как Билл / Уильям. Эта проблема была изучена в более широком контексте синонимов в целом: вывод их из статистики того, какие слова обычно встречаются в одном и том же контексте в большом текстовом корпусе, таком как Интернет. Вы можете попробовать объединить этот подход со списком имен, таких как Moby Names ; Я не знаю, было ли это сделано раньше.

Вот несколько указателей.

0 голосов
/ 22 февраля 2009

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

Я думаю, вы могли бы взглянуть на некоторые из следующих ссылок: (Забавно, до сих пор никто не упомянул SoundEx)

В основном SoundEx позволяет оценить уровень сходства в похожих звучащих словах. Эта функция также доступна в SQL 2005.

В качестве дополнительной проблемы вместо того, чтобы возвращать похожие результаты, пользователю может оказаться более интуитивно понятным использование сценария на основе AJAX для доставки похожих звуковых имен до того, как пользователь начнет свой поиск. Таким образом, вы можете показывать пользователю «похожие имена» или «вы имели в виду ...» данные.

...