Моделирование данных: иерархия географических местоположений - PullRequest
Новая
       6

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

4 голосов
/ 24 ноября 2010

Я хочу, чтобы мои пользователи могли указывать свое местоположение, чтобы я мог наносить их на карту. Получив адрес, я использую API Карт Google, чтобы получить их координаты широты и долготы и сохранить их в базе данных.

Кроме того, я хочу разрешить пользователям выполнять поиск других пользователей в зависимости от местоположения. Используя API Карт Google, я также могу получить, скажем, страну / штат / город для адреса (или широты / долготы). Моя проблема в том, что я не знаю, как хранить страну / штат / город таким образом, чтобы:

  • Данные связаны с конкретным пользователем
  • Нет избыточности данных

Проблема, я думаю, заключается в том, что если Пользователь-1 и Пользователь-2 вводят адрес, в результате чего страна становится "США", я думаю, мне нужно знать, что Пользователь-1 и Пользователь-2 оба из США - - И что «США» хранится только один раз в БД.

Когда пользователи ищут других пользователей, я думаю, что я должен позволять им искать пользователей только в США, если у меня есть пользователи из США. Это означает, что пользователь-1 и пользователь-2 - единственные 2 пользователя из США, если пользователь-1 и пользователь-2 удаляют свои профили, я больше не должен разрешать поиск пользователей в США.

Мои идеи концептуально неверны? В любом случае, как мне смоделировать эту информацию? Я использую MySQL.

1 Ответ

6 голосов
/ 25 ноября 2010

Ваши цели и намерения верны (не сдавайтесь!), Вам может понадобиться помощь, чтобы переступить черту, вот и все. Чем больше у вас понимания и опыта в области моделирования данных и нормализации, тем проще будет. Поэтому проводите как можно больше исследований и упражнений (ТАК или Интернет - не лучший способ научиться чему-либо).

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

    • Это модель данных с высокой нормализацией, в 5NF.

    • Но есть еще нормализация, которую можно сделать; больше дублирования, которое можно удалить. Это не стоит, если вы действительно не заинтересованы, например. вам нужно искать в LastNames и т. д.
      .

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

    • Адрес - это конкретный дом или блок (квартира), и он не дублируется. Два человека, проживающие по одному и тому же адресу, будут использовать одну строку адреса.

    • Эта структура обрабатывает «любое» географическое положение. Обратите внимание, что в некоторых странах нет государства; в некоторых штатах нет округов; в некоторых городах нет пригородов; и т. д. Вместо того, чтобы встроить все эти исключения в модель данных, я сохранил иерархию "чистой". Вам все еще нужно будет обработать это в вашем SQL (независимо от того, проста ли модель без исключений или есть исключения; потому что это реальный мир), и не отображает состояние для состояния без страны. Все, что вам нужно, это строка для государства, не имеющего StateCode из CHAR (0), которая идентифицирует условие.

    • Я разместил Долготу и Широту на уровне Пригорода, предполагая, что это то, что ваши пользователи могут легко выбрать с помощью GoogleMaps, и потому что уровень улицы будет иметь ограничения (может быть мелкозернистым и вызвать дублирование; или недостаточно мелкозернистый для городов с очень длинными улицами). Легко изменить.

    • На данный момент, я предлагаю вам не беспокоиться об идентификации пользователей в одной и той же стране, сначала посмотрите, можете ли вы обработать SQL для идентификации пользователей в одном и том же пригороде (а не на улице, это легко). После этого мы можем иметь дело с городом, округом, страной и т. Д.

    • Я думаю, что другие поиски, которые вы обнаружите, не требуют усилий; посмотреть, если вы согласны.

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

Ссылка на модель данных GLS (плюс ответ на другой вопрос)

Ссылка на нотацию IDEF1X для тех, кто не знаком со стандартом реляционного моделирования.

...