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

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Итак, это вообще поможет? До точки. Это предполагает то, что вы хотите реализовать:

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

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

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

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