Вариации имени в базе данных

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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

Эндрю

Ответ 5

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

В принципе, как:

SELECT ProductId, ProductName FROM ProductModel WHERE CONTAINS (CatalogDescription, 'FORMSOF (THESAURUS, metal)')

Отъезд: 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

Ответ 6

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

Ответ 7

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

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

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

-Adam

Ответ 8

Термин, который вы ищете, - это Hypocorism:

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

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

Я бы пошел со структурой вроде этого:

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

Одна проблема, с которой вы столкнетесь, состоит в том, что разные имена могут иметь тот же самый гикоризм (Albert → Al, Alan → Al)

Ответ 9

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

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