Можно ли сравнить две таблицы, если между ними нет общего ключа? - PullRequest
2 голосов
/ 18 сентября 2009

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

Спасибо.

Ответы [ 4 ]

3 голосов
/ 18 сентября 2009

Я бы попробовал сопоставить, используя алгоритм Double Metaphone , который является более сложным алгоритмом типа SOUNDEX.

Вот реализация MySQL .

2 голосов
/ 18 сентября 2009

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

Вам нужно что-то, что может сравнивать две строки и возвращать оценку за сходство, оценку 100%, означающую идентичность. Что-то вроде алгоритма Яро-Винклера . Альтернативные алгоритмы включают Метафон (или Двойной Метафон) и Soundex(). Soundex() - самое грубое решение.

Альтернативным решением будет использование специализированного текстового индекса. Крутая вещь в этом подходе состоит в том, что мы можем указать тезаурус для указания синонимов, которые сглаживают несущественные различия (INC = INCORPORATED, CO = COMPANY и т. Д.).

Oracle и SQL Server включают такой инструмент, но я не знаком с MySQL.

1 голос
/ 18 сентября 2009

SOUNDEX () поможет вам в определенной степени. Но это далеко от совершенства.

soundex (string1) ожидается равным soundex (string2), даже если string1 и string2 пишутся по-разному. Но, как я уже сказал, он далек от совершенства.

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

0 голосов
/ 18 сентября 2009

Ну, нет 100% гарантированного правильного пути, нет. Но вы, вероятно, можете добиться некоторого прогресса, преобразовав все «грязные» столбцы в более каноническую форму , например. Путем использования всех заглавных букв подряд вырезаются начальные и конечные пробелы и обеспечивается не более 1 пробела. Также такие вещи, как изменение имен формы «SMITH, JOHN» на «JOHN SMITH» (или наоборот - просто выберите форму и следуйте ей). И, конечно, вы должны сделать копии записей, не меняйте оригиналы. Вы можете поэкспериментировать с отбрасыванием дополнительной информации (например, «JOHN SMITH» -> «J SMITH») - вы обнаружите, что это меняет баланс ложных срабатываний на ложные отрицания.

Я бы, вероятно, воспользовался подходом назначения оценки сходства для каждой пары записей. Например. если канонизированные имена, адреса и адреса электронной почты точно совпадают, присвойте 1000 баллов; в противном случае вычтите (несколько кратное) расстояние Левенштейна из 1000 и используйте его. Вам нужно будет придумать свою собственную схему подсчета очков, поигравшись и решив относительную важность различий разных типов (например, другая цифра в номере телефона, вероятно, важнее, чем разница в 1 символ в именах двух людей). Затем вы сможете экспериментально установить оценку, выше которой вы можете с уверенностью присвоить статусу «дубликат» паре записей, и более низкую оценку, выше которой требуется ручная проверка; ниже этого балла, мы можем с уверенностью сказать, что 2 записи не дубликаты.

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

...