Моделирование географических местоположений в реляционной базе данных

Question

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

Locales (ID, LocationName, ParentID), где автономные местоположения (например, страны, например, США) являются родителями самих себя. Таким образом, я могу иметь произвольно глубокое гнездование «политических единиц» (СТРАНА> ГОСУДАРСТВО> ГОРОД или СТРАНА> ГОСУДАРСТВО> ГОРОД> УНИВЕРСИТЕТ). Некоторые запросы обязательно потребуют рекурсии.

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

Answer 1

Возможно, вы захотите взглянуть на сайт Freebase.com как на сайт, на котором было открыто обсуждение того, что означает «местоположение», и что это означает, когда местоположение включено в другое. Такие вопросы могут вызвать много дискуссий.

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

Answer 2

Звучит как хороший подход ко мне. Единственное, что я не понимаю при чтении вами сообщения, - это то, что означает «родители самих себя» - если это означает, что языковой стандарт не имеет родителя, вам лучше использовать null, чем сам идентификатор.

Answer 3

Я думаю, вы можете переусердствовать. Причина в том, что большинство систем просто хранят адреса и, возможно, таблицу стран. Вот некоторые вещи, которые нужно посмотреть:

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

2. Я не уверен, что у вас даже есть только одна иерархия. Университет Брауна располагает средствами в Провиденсе, Рио и Бристоле, Рио. Единственное чистое решение состоит в том, чтобы иметь двойную иерархию с двумя кампусами, каждая из которых принадлежит к их соответствующим городам в одной иерархии, но они принадлежат Брауновскому университету по другой иерархии. (Университет в основном не похож на политический регион. Вы не должны их смешивать.)

3. Как насчет почтовых индексов? Некоторые почтовые индексы охватывают несколько городов, иногда город разбит на несколько почтовых индексов. И (редко) некоторые почтовые индексы даже пересекают государственные линии. (Согласно Википедии, по крайней мере ...)

4. Как вы введете данные? Создание базы данных путем разбора условно-отформатированных адресов может быть затруднено при учете адресов тщеславия, альтернативных имен для определенных улиц, разных международных форматов и т. Д. И я думаю, что каждый адрес по иерархии был бы PITA.

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

Извините за крайний пессимизм, но я сам пошел по этой дороге. Это логично красиво и элегантно, но на практике это не так хорошо.

Answer 4

Я бы подумал об этом, так как это может быть не обязательно. Почему бы просто не использовать текстовое поле и позволить пользователям вводить адрес?

Запомните KISS principle (Держите его простым, глупым).

Answer 5

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

Расположение (LocationID, LocationName) - Основной строительный блок

LocationGroup (LocationGroupID, LocationGroupName, ParentLocationGroupID) - Это может эффективно инкапсулировать несколько иерархий. У вас есть один корневой узел, а затем вы можете создать несколько независимых ветвей. Например. вы можете сначала разделить по состоянию, а затем создать несколько подъярусов, например. ZIP/city/xxxx

LocationGroupLocation (LocationID, LocationGroupID) - Вот как вы связываете местоположение с одной или несколькими иерархиями. Например. вы можете связать свой дом с ZIP, а также с городом ... Что вам нужно реализовать, это ограничение, которое вы не должны связывать с любыми двумя иерархиями, где один из них является родителем другого (поскольку отношения уже неявные).

Answer 6

Я согласен с другими сообщениями, которые вам нужно быть очень осторожными здесь, о ваших требованиях. Место может стать сложной проблемой, и именно поэтому системы ГИС так заявлены.

Если вы уверены, что вам просто необходима базовая структура иерархии, у меня есть следующие предложения:

• Я поддерживаю предыдущий комментарий, что элементы уровня корня не должны иметь себя в качестве родителя. Элементы корневого уровня должны иметь нулевое значение для родителя. Всегда будьте осторожны с помещением данных в поле, которое не имеет смысла (т. Е. «Специальное» значение для представления данных). Эта практика редко бывает обязательной и способ, используемый в сообществе devleoper.
• Рассмотрите XPath/XML. Это что-то, что нужно учитывать для записи структуры иерархии, а также для обработки/анализа данных при поиске. Если вы используете MSSQL Server, выражения XPath в операторах выбора идеально подходят для таких задач, как возврат пути к полному местоположению/иерархии записи, поскольку код является простым и результаты быстрые.

Answer 7

Для географических местоположений Вы можете захотеть разрешить адрес в широту, долгота массив (возможно, с помощью Google карты и т.д.) для расчета близостей и т.д .. Для геополитической вложенности ... Я бы с ответом ПОЦЕЛУЯ ,

Если вы действительно хотите его смоделировать, возможно, вам нужны типы, чтобы быть более родовыми ... Страна -> Штат -> Графство -> Город -> Местность -> Город -> Пригород -> Улица или PO Box - > Номер -> -> Квартира и т. Д. -> Учреждение (Университет или работодатель) -> Отдел -> Подразделение-1 -> подразделение-н ... Вы уверены, что не можете делать KISS?

Answer 8

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