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

Question

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

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

Я также буду использовать эти данные, чтобы определить, какие страницы мои пользователи хотят посетить, поэтому он должен быть простым для поиска запрос типа «/ США/Калифорния/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

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

Answer 3

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

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

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

Answer 4

Идите по нормализованному маршруту. Соединение таблиц НЕ медленное или сложное. PK каждой таблицы будет целым числом с кластеризованным индексом. У внешних ключей будет указатель. Присоединение будет летать.

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

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

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