Каков наилучший способ хранения географической информации в отношении БД?

Question

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

Мое текущее решение состоит в том, чтобы в моей таблице было 4 дополнительных поля (во всех интересующих меня странах есть 2 или 3 административных деления) и фильтр по строкам. Но я понимаю, что это плохое решение и хотел бы нормализовать мой стол.

Я также буду использовать эти данные, чтобы определить, какую страницу хотят посетить мои пользователи, поэтому поиск запроса должен быть простым, например "/usa/california/san_fransisco/..."

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

Есть ли лучший способ сделать это?

Answer 1

Нормализация, безусловно, путь.Базы данных разработаны таким образом.Да, запрос может выглядеть долго, но это не так уж плохо.Это может выглядеть примерно так:

select * --or whatever fields you need
  from Customer
       left outer join City    on (Customers.CityID = City.CityID)
       left outer join State   on (City.StateID     = State.StateID)
       left outer join Country on (State.CountryID  = Country.CountryID)
 where CustomerID = 1234

Answer 2

Мое текущее решение состоит в том, чтобы в моей таблице было 4 дополнительных поля (во всех странах, в которых я заинтересован, есть 2 или 3 административных деления) и фильтр по строкам.Но я понимаю, что это плохое решение и хотел бы нормализовать мой стол.

Я не думаю, что это плохое решение.Хранение простой географической / адресной информации для каждой строки и использование WHERE для извлечения всех соответствующих записей является довольно стандартной процедурой.Использование внешнего ключа для ссылки на отдельную таблицу будет дополнительной работой и не будет быстрее.

Однако поиск / запрос с использованием интерфейса RESTful (как вы и предлагали) - хорошая идея.

Answer 3

Пройдите нормализованный маршрут. Присоединение к таблицам НЕ является медленным или сложным. PK каждой таблицы будет целым числом с кластерным индексом. Внешние ключи будут иметь индекс. Объединение будет летать.

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

Но есть случай для нормализации. Есть миллионы адресов. Возможно, будет невозможно ввести все адреса в вашем приложении. Таким образом, вы будете полагаться на ..... свободный ввод текста от пользователя. В этом случае вас не заботит точная правильность или дубликаты, вы вынуждены просто принять то, что на вас брошено, из-за невозможности получить исчерпывающие данные для проверки. И вы бы предпочли не вставлять в «справочные» таблицы, поскольку не доверяете вводу с самого начала.

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

Answer 4

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