SQL алгоритм или функция нечеткой строки / соединения слов - PullRequest
Новая
       12

SQL алгоритм или функция нечеткой строки / соединения слов

0 голосов
/ 22 ноября 2018

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

Моя таблица структурирована следующим образом 

CREATE TABLE [dbo].[Places] (
    [place_id] [int] NOT NULL ,
    [place_name] [varchar] (40),
    [country_id] [varchar] (2),
    [latitude] [decimal](8, 6) NULL ,
    [longitude] [decimal](9, 6) NULL ,
    [other_place_id] [int] NULL
)

Вторая таблица имеет аналогичную структуру 

CREATE TABLE [dbo].[OtherPlaces] (
    [other_place_id] [int] NOT NULL ,
    [other_place_name] [varchar] (40),
    [country_id] [varchar] (2),
    [latitude] [float] NULL ,
    [longitude] [float] NULL ,
    [place_id] [int] NULL
)

Я могу запустить простой запрос на совпадение, например 

Select p.*, o.other_place_id
from Places p
JOIN OtherPlaces o
on p.country_id = o.country_id
and p.place_name = o.other_place_name
where abs(60*(p.latitude - o.latitude)) < 5
and abs(60*(p.longitude - o.longitude)) < 5

, и это будетподберите одинаковые места, расположенные на расстоянии 5-10 миль друг от друга.

Это будет соответствовать примерно 75% записей.

Оставшаяся группа имеет множество проблем:

  1. Неправильные местоположения (N / SE / W неверно илипросто численно неверно)
  2. Альтернативное написание / использование языка (см. ниже)
  3. Места с альтернативными значениями country_id (на спорных территориях или просто неправильно введены)
  4. Места, неизвестные ни одному из данныхset

Предполагая, что я доволен правдивостью сопоставления в этом первом запросе, я просто запустил бы эквивалентный UPDATE запрос UPDATE Places SET other_place_id = o.other_place_id из Places p ПРИСОЕДИНЯЙТЕСЬ к OtherPlaces o на p.country_id = o.country_id и p.place_name = o.other_place_name где abs (60 * (p.latitude - o.latitude)) <5 и abs (60 * (p.longitude - o.longitude)) <5 </p>

Это позволит затем выполнять дополнительные запросы с использованием (псевдо) кода, такого как Select p. , o.other_place_id из Places p JOIN OtherPlaces o on p.country_id = o.country_id и p.place_name SOUNDSLIKE (o.other_place_name), где abs (60 (p.latitude - o.latitude))

Это позволило бы мне создать функцию SOUNDSLIKE, которая могла бы сопоставлять залив Пальмейра с Байей де Пальмейрой и Сен-Мартан с Сен-Мартеном.

Сценарий альтернативного орфографии имеет 3 аспекта:

  1. Альтернативные языки
  2. Неправильные орфографические ошибки при вводе данных
  3. Локальное именование

1 и 3 могут быть связаны, но часто не связаны.

Информация о местоположении WRT, между двумя наборами данных часто будут небольшие различия, что является приемлемым.Тем не менее, большие расхождения могут возникнуть.Некоторые из них действительны (то есть, что такое широта / длина для Сингапура? Это большой маленький остров), некоторые - ошибки транскрипции / транспозиции при вводе данных.А в некоторых случаях нет данных о местоположении: - (

У меня такой вопрос, есть ли лучший способ управления процессом сопоставления, чем серия итеративных запросов, постоянно уточняющих и исключающих предыдущие совпадения?

И как лучше всего управлять функциональностью SOUNDSLIKE? Я посмотрел на эту ветку и добавил функции Левенштейна и Метафона, но я не уверен, что любая из них использует какое-либо тезаурусное сопоставление для отдельных словЯ думаю, что тезаурус / словарь может быть полезным инструментом, так как я определил повторные подсчеты слов в 2 наборах данных и, конечно, у меня есть списки эквивалентных слов / терминов для создания поиска.

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

TIA

...