Как я могу сопоставить вводимые пользователем данные с неоднозначными названиями городов?

У нас есть набор таблиц, показанных ниже, которые мы используем для других наших таблиц для ссылки на данные о местоположении. Вот некоторые примеры:

  • Найдите все компании в пределах X миль от X City
  • Создайте местоположение профиля компании как X City

Table Schema

Мы решаем проблему нескольких городов с одинаковыми названиями, сопоставляя их с государством, но теперь мы столкнулись с другим набором проблем. Мы используем автозаполнение Google для геокодирования и сопоставления запросов пользователей с нашими городами. Это работает довольно хорошо, пока формат Google не отличается от нашего.

Пример: St. Louis !== Saint Louis и Ameca del Torro !== Ameca Torro

Есть ли способ нечеткого совпадения городов в наших запросах?

Наш запрос для сопоставления городов теперь выглядит так:

SELECT c.id
FROM city c
INNER JOIN state s
ON s.id = c.state_id
WHERE c.name = 'Los Angeles' AND s.short_name = 'CA'

Я также рассмотрел денормализующий город и просто сохраняю координаты для выполнения поиска радиуса. Сейчас в нашей таблице company около 2 миллионов строк, поэтому поиск по радиусу будет выполняться по этой таблице, а не по таблице city с JOIN в company. Это также означает, что мы не сможем создавать собственные регионы (просто так или иначе) для городов и добавлять другие атрибуты в города в будущем.

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

2
задан Matt Weber 27 June 2019 в 19:35
поделиться

1 ответ

Короткий ответ - то, что можно использовать функциональность полнотекстового поиска Пост-ГРЭС со специализированной поисковой конфигурацией.

Начиная с Вашего контакта с названиями места, Ваш, вероятно, не хотят происходить, таким образом, можно использовать простую конфигурацию в качестве начальной точки. Можно также добавить стоп-слова, которые имеют смысл для названий места (с примерами выше, можно, вероятно, рассмотреть "Св.", "Святого" и "del" как стоп-слова).

А довольно основная схема установки Вашего специализированного ниже:

  1. Создают файл стоп-слов и помещают его в Ваш $SHAREDIR/tsearch_data каталог Postgres. См. https://www.postgresql.org/docs/9.1/static/textsearch-dictionaries.html#TEXTSEARCH-STOPWORDS.
  2. Создают словарь, который использует этот список стоп-слов (можно, вероятно, использовать pg_catalog.simple в качестве шаблонного словаря). См. https://www.postgresql.org/docs/9.1/static/textsearch-dictionaries.html#TEXTSEARCH-SIMPLE-DICTIONARY.
  3. Создают поисковую конфигурацию для названий места. См. https://www.postgresql.org/docs/9.1/static/textsearch-configuration.html .
  4. Изменяют Вашу поисковую конфигурацию для использования словаря, который Вы создали на Шаге 2 (cf. ссылка выше).

Другое соображение состоит в том, как рассмотреть интернационализацию. Кажется, что проблемой для Вашего второго примера (Ameca del Torro по сравнению с Ameca Torro) мог бы быть испанский по сравнению с английским представлением имени. Если это так, Вы могли также рассмотреть хранение и "локализованный" и "универсальное" (например, английский язык) версия названия города.

В конце, Ваш запрос (использующий полнотекстовый поиск) мог бы быть похожим на это (где 'места' являются названием Вашей поисковой конфигурации):

SELECT cities."id"
FROM cities
    INNER JOIN "state" ON "state".id = cities.state_id
WHERE
    "state".short_name = 'CA'
    AND TO_TSVECTOR('places', cities.name) @@ TO_TSQUERY('places', 'Los & Angeles')
1
ответ дан Zack 3 July 2019 в 04:10
поделиться
  • 1
    Трудно сказать - there' s jsperf, хотя один want' s для измерения его. OTOH эти два оператора имеют полное различное значение. Только требуя числа (и не целое число) ' + ' так или иначе один символ короче. – Aki Suihkonen 1 March 2013 в 06:58
Другие вопросы по тегам:

Похожие вопросы: