Заполнение таблицы внешнего ключа переменным пользовательским вводом

Question

Я работаю над сайтом, который будет основан на данных, предоставленных пользователями, отправлено с использованием обычной формы HTML.

Чтобы упростить мой вопрос, допустим, что в форма: «Имя пользователя» и «Страна» (это только пример, а не актуальный сайт).

В базе данных будет две таблицы: "страны" и "пользователи" где "users.country_id" является внешним ключом для таблицы "стран" (Один-ко-многим).

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

Поскольку одна страна может иметь несколько альтернативных названий, введите как Chile, Chili, Chilli сгенерируют 3 разных записи в таблица стран, но на самом деле есть только одна страна. Когда я ищу записи из Чили, Чили и Чили не будут включены.

Так что мой вопрос - что было бы лучшим способом справиться с ситуация, подобная этой, с такими условиями, что исходная база данных пусто, другие ресурсы недоступны и все основано на пользовательский ввод?

Как я могу организовать это так, чтобы Чили, Чили и Чили могли следует рассматривать как одну страну с минимальным ручным вмешательством.

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

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

Answer 1

Поисковые системы, основанные на файлах (Lucene, Sphinx и т. Д.) Или базе данных (Oracle Text, MSSQL Fulltext), решают эту проблему с помощью тезауруса. То есть они собирают слова вместе на основании того, что они являются синонимами. Квалификация быть синонимом более жесткая, чем в книге Роже, но принцип тот же. Синонимы связывают сокращения, сокращения и общие орфографические ошибки. Так, например, поисковый тезаурус может идентифицировать street и st как одно и то же. Хотя контекст - это все: в строке «St Pancras Road» st является синонимом saint .

.

Так это тебе вообще помогает? К точке. Он предлагает то, что вы хотите реализовать:

string      | canonical
------------+----------
street      |
st          | street
strete      | street
Chile       |
chilly      | Chile
chili       | Chile

К сожалению, создание и поддержание тезауруса требует человеческой изобретательности и усилий. Построение таксономии требует экспертизы; Отслеживание новых дополнений требует времени. Другое дело, что даже с тезаурусом совпадения остаются вероятностными: MoMA может быть таким же, как Музей современного искусства , но совпадает ли это с SFMOMA или NYMOMA ? Не совсем, но, возможно, на 90% то же самое?

Альтернативным подходом было бы сделать то, что SO делает с тегами. Когда вы отметили свой вопрос, появилось выпадающее окно с предложением доступных тегов. Когда вы набрали больше букв, список сузился. Это не глупо, засвидетельствуйте наличие таких тегов, как tsql и t-sql, но это довольно хорошо. У SO также есть резервная копия, которая должна предоставить опытным пользователям список свежеиспеченных тегов, чтобы они могли исследовать эти чеканки и, возможно, отменить их. Но это все еще напоминает ручной процесс.

Увы, нет алгоритма, который мог бы сказать, что MoMA такой же, как Музей современного искусства , не говоря уже о том, ссылается ли он на учреждение в Новом Йорк или Сан-Франциско.

Answer 2

Вы не можете программно определить, что Чили должно совпадать с Чили , что совпадает с Чили . На примере страны у вас может быть список стран, которые вы вводите в свою базу данных, и выпадающий список, из которого пользователи могут выбирать.

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

Вы могли бы придумать алгоритм , который связывает слова, которые похожи , но ИМХО, которые просто требуют недетерминированных результатов (катастрофа). Например (на примере, отличном от вашего в стране), вы можете программно определить, что слова fight и sight отключены только на одну букву, поэтому они похожи. Но действительно ли они? То, что эти два слова синтаксически близки, не означает, что они тоже семантически близки. И я предполагаю, что это то, что вы после.

Answer 3

Я бы сказал, чтобы использовать раскрывающийся список для страны, и вы можете легко заполнить его с помощью JavaScript. Вы можете найти список всех стран здесь http://openconcept.ca/blog/mgifford/text_list_all_countries

Что касается вашего вопроса о нормализации, я не вижу никаких проблем с дизайном в соответствии с вашим примером