Создание нескольких индексов для объединения таблиц для соответствия нечетким соответствиям

Question

Я пытаюсь сопоставить данные почтового адреса, предоставленные пользователем, в набор данных адреса. Я хочу индексировать оба набора данных и присоединяться к индексированному полю. В идеальном мире это будет использовать ключ, состоящий из полного адреса (например, WHERE REF_ADDR = INPUT_ADDR даст 100 W Main St, Springfield, OH 45502 = 100 W Main St, Springfield, OH 45502). Конечно, адреса редко бывают идеальными, поэтому у меня есть сценарий, который может учитывать различия с использованием нечеткой логики. Однако, поскольку этот скрипт очень медленный, я хочу уменьшить количество кандидатов из базового набора данных, к которому выполняется процесс сопоставления, прежде чем он будет использоваться. Чтобы найти всех потенциальных кандидатов, я намереваюсь создать индексированный ключ, который выводится из отдельных компонентов адреса, которые будут использоваться для присоединения. Проблема в том, что один ключ не будет захватывать всех возможных кандидатов. Скорее всего, мне нужно создать несколько индексированных ключей, чтобы захватить всех кандидатов.

Например, индексированный ключ в форме 100 WMNST 455 для адреса 100 W Main St, Springfield, OH 45502 будет полезен большую часть времени, но может быть любое количество ошибок адреса, которые не будут пойманы таким ключом. Чтобы учесть все потенциальные ошибки, которые распознает процесс сопоставления, мне, вероятно, потребуется реализовать по меньшей мере несколько индексированных ключей для соединения.

Мне интересно, есть ли у кого-нибудь рекомендации по решению этой проблемы. Справочный набор данных состоит из записей 40M, а предоставленные пользователем данные адреса обычно составляют около 10 000 записей. Было бы более эффективным просто использовать LIKE и OR запросы в полях адреса в отличие от метода, который я предлагаю? Это не является необычным встретить следующие варианты в последнем набор данных (размещено для скрипта):

Address: 100 W MAIN 
City: 
Zip: 45502 

Address: 100 MAIN ST 
City: SPNGFLD 
Zip: 

Address: 100 W MAIN STREET 
City: SPRINGFIELD 
Zip: 54502 

Address: 100 MAIN 
City: NORTHRIDGE 
Zip: 45502 

Answer 1

В зависимости от того, какой системы DB вы используете вы должны попробовать, чтобы увидеть, если какой-либо встроенные функциональные возможности могут быть использованы. Например, если вы работаете над SQL SERVER, параметры, о которых я могу думать, это «Change Data Capture», «Full text search», «Filtered Index» и т. Д. ... Но независимо от системы БД, если вы хотите разработать ваш собственный, который может быть реализован в любой системе БД, тогда это может вас заинтересовать.

Что вы спросите, это предложить некоторые параметры индексирования, но для меня это неправильный вопрос, так как вы будете ограничены очень небольшим количеством вариантов, поскольку данные растут в таблице и/или ваши критерии поиска становятся сложными. Если сам дизайн схемы не масштабируется, тогда вы не сможете более быстро реализовать более высокие показатели производительности в экстремальных случаях.

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

Под этим означает «Точное совпадение», «Подобное совпадение», «Начать с А», «Заканчивается на А» или «Содержать А».

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

Нам понадобятся 5 столов.

Теперь вопрос в том, Как эта схема поможет или улучшить свой нечеткий поиск?

Обратите внимание, что каждая таблица имеет только 2 Clumns с INTEGER и/или типа STRING, мы можем иметь кластерный индекс для каждой таблицы, которая включает в себя как столбец ..

Поскольку мы выделили данные по точности вы можете дать чтобы пользователь мог получить доступ к точной информации. это уменьшит нагрузку поиска, а также выполнит операцию поиска.

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