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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Помните принцип KISS (Держите это простым, глупый)

Answer 6

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

Если вы действительно хотите смоделировать его, возможно, вам нужно, чтобы типы были более общими ... Страна -> Штат -> Уезд -> Город -> Местность -> Город -> Пригород -> Улица или почтовый ящик -> Номер -> -> Квартира и т. Д. -> Учреждение (Университет или Работодатель) -> Подразделение -> Подразделение-1 -> Подразделение-n ... Вы уверены, что не можете сделать КИСС?

Answer 7

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

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

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

Answer 8

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