лучший дизайн базы данных для городских таблиц zip & state

Question

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

решение для одной таблицы (отношения не могут)

[места] locationID locationParent (FK для locationID - 0 для записей состояния) locationName (город, штат) locationZIP

---

две таблицы (со связями, ограничениями FK, ссылочной целостностью)

[состояние] stateID StateName

[город] CityId StateID (FK для state.stateID) название города ZipCode

---

три стола

[состояние] stateID StateName

[город] CityId StateID (FK для state.stateID) CITYNAME

[застежка-молния] zipID cityID (FK для city.cityID) zipName

---

Затем я прочитал в почтовые индексы и как они назначены. Они не связаны конкретно с городами. В некоторых городах более одного почтового индекса (хорошо, все равно будет работать), но некоторые почтовые индексы находятся в более чем одном городе (о, хватит), а некоторые другие почтовые индексы (очень мало) находятся в нескольких штатах! Также некоторые почтовые индексы даже не находятся в том же состоянии, что и адрес, к которому они принадлежат. Кажется, почтовые индексы сделаны для идентификации маршрута перевозчика, а некоторые отдаленные места лучше всего обслуживать почтовые отделения в соседних городах или штатах.

Кто-нибудь знает хорошее (не идеальное) решение, которое учитывает это, чтобы минимизировать несоответствия по мере роста базы данных?

Answer 1

На самом деле существует некоторая база данных (с одной таблицей), которую USPS выпускает каждый год с почтовыми индексами и штатами, а также округами и штатами. Я бы посмотрел на это. У меня есть (устаревшая) копия этого. Схема довольно проста:

<strike>
ZIPCODE nvarchar(5) not null
CITY nvarchar(50) null
STATE nvarchar(2) null
STATECODE nvarchar(50) null
COUNTY nvarchar(50) null
COUNTYCODE nvarchar(50) null
</strike>

(см. Ниже)

edit: Кроме того, я бы позволил вашим пользователям добавлять новый почтовый индекс (с указанием города и округа и т. Д.), Поскольку почтовые индексы добавляются все время ..

http://www.usps.com/ncsc/addressinfo/addressinfomenu.htm

редактирование: На самом деле, я думаю, что я не прав. У меня нет официальной копии их базы данных ... Я скачал один из их примеров файлов, и их схема кажется довольно сложной.

Answer 2

Спасибо за все ответы. Я хотел дать отзыв и мое решение, если кто-то заинтересовался. Вопрос был «Как хранить / извлекать почтовые индексы, города и штаты?»

Джон Зигель дал мне довольно обнадеживающий ответ об использовании: Страна Регион (штат / провинция) город с отношениями один ко многим.

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

Для всех, кто заинтересован, мое решение таково:

[состояние]; stateID; StateName

[местоположение]; locationID; StateID (FK); название города; zipID

[location.stateID] является отношением внешнего ключа с отношением один-ко-многим к [state.stateID]. Я решил сохранить ZIP с таблицей местоположений, поскольку уникальные ZIP не имеют прямого отношения к уникальному городу. Также кажется, что почтовые индексы не являются основой для определения границ города / штата, скорее они предназначены для целей USPS и фактически указывают маршрут перевозчика и почтовую зону доставки, которая может охватывать города или даже штаты. Можно добавить еще одну запись местоположения с тем же названием города и дополнительным ZIP. Таким образом, поиск ZIP может привести ко всем городам, а поиск городов может привести ко всем почтовым индексам, если это необходимо.

Answer 3

Я не знаю, если вы интернационализируете свое приложение, но общая конструкция такова, с отношением один ко многим со следующим элементом:

Страна
Регион (штат / провинция)
Город

Этого обычно достаточно, чтобы иметь возможность фильтровать ваши данные осмысленным образом. Поверь мне в этом: ты не хочешь разбираться в технических особенностях географического деления земли.

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

Answer 4

Это зависит от того, важнее ли целостность данных, нормализация или производительность.

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

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

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

Я бы поставил эти внешние ключи как поля в домашнем хозяйстве.

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

Answer 5

Не существует единой подходящей модели для этой потребности - есть десятки. Чтобы узнать, что лучше для вас, зависит от дополнительной информации, например:

• производительность и производительность - что беспокоит избыточность?
• функциональность - какой анализ данных будет выполнен?
• исторические данные - нужно ли сохранять старые данные? обратите внимание, что почтовые индексы меняются, и это делает недействительными некоторые из предложенных решений
• интернационализация
• язык
• у вас есть другие виды локаций? Возможно, вам понадобится более абстрактное решение, которое может объединить физическое с электронным местоположением - например, если ваш пользователь хочет выбрать предпочтительный метод контакта и т. Д.
• Вы хотите разрешить совместное использование местоположений?
• какая-либо другая информация о физическом местонахождении также сохраняется или с большой вероятностью будет добавлена? Как округ, страна, широта и долгота и т. Д.?