Дизайн стола

Question

Мне было интересно, это хороший дизайн, предполагая таблицы следующим образом

ADDRESS(id, address, city_fk, stateFK, countryFK),
CITY(id, name, stateFK, countryFK),
STATE(id, name, countryFK),
COUNTRY(id, name)

Обратите внимание, как страна fk повторяется в 3 таблицах? а состояние фк повторяется в 2 таблицах? Может кто-нибудь сказать мне, если это хороший дизайн? Если так, то почему? Потому что я не вижу необходимости повторять это так часто.

Приветствия

Answer 1

Вы хотите что-то еще, как это:

• АДРЕС (id, адрес, city_fk)
• ГОРОД (id, name, state_fk)
• STATE (id, name, country_fk)
• СТРАНА (id, имя)

И если бы это был я, я бы немного переименовал поля:

• АДРЕС (id, адрес, city_id)
• CITY (id, city, state_id)
• STATE (id, штат, country_id)
• СТРАНА (id, страна)

Answer 2

Наверное, мой вопрос "Хороший дизайн для чего?" Если точная целостность адреса абсолютно необходима для вашего дизайна, то это может стать началом плодотворной дискуссии. С другой стороны, если цель состоит в том, чтобы собирать адреса и иметь возможность хранить их во всем многообразии, которое вы ожидаете получить от реальных пользователей, вы можете рассмотреть что-то с немного большей гибкостью: то есть меньше таблиц с дополнительными полями и хороший набор дружественных правил проверки в пользовательском интерфейсе.

Answer 3

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

Answer 4

Возможно, вы слишком нормализуетесь?

Хотя вы снижаете стоимость повторяющихся данных, вы, возможно, отрицаете их, требуя 3 или 4 объединения для получения целого адреса ...

Лично я бы придерживался:

Адрес:

• ID * +1010 *
• Адрес улицы (например, 123 Joe Street)
• Город
• Государство
• Почтовый индекс (ZIP)
• Страна (например, США или Австралия)

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

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

Answer 5

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

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

Точно так же вы можете иметь адрес, который находится в стране Австралии и штата Техас (в США) и города Ксолотлотль ^a в Перу в Южной Америке. Я не хотел бы объяснять вашу схему почтальону, когда он выслеживает вас.

Как вы решаете это? Вероятно, вам следует указывать только город по адресу, затем штат из города, а затем страну из штата.

Но адреса - хитрый зверь, и форма, которую они принимают, во многом зависит от того, где они находятся. У некоторых есть округа, некоторые города пересекают государственные границы и т. Д.

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

Моя первая попытка была бы:

ADDRESS(id, address_including_city, stateFK),
STATE(id, name, countryFK),
COUNTRY(id, name)

Вам нужно было бы различать «идентичные» штаты в разных странах (например, Вашингтон и Западная Австралия, обе из которых являются WA), но вы могли бы легко показать страну на экранах ввода данных, чтобы оператор знал, в какой штат они входят ( или, скорее всего, сначала они выберут страну, а выбор штата будет сокращен).

---

^a Насколько я знаю, Ксолотллотль - не настоящий город, это всего лишь тот, который я придумал, который звучит как те прекрасные древние имена инков.

Answer 6

Подумайте: если я знаю штат, а штат ФК - это страна, я транзитивно знаю страну, и это лишняя денормализация, чтобы включить ее снова.

Если я знаю город, а город ФК - это штат, я транзитивно знаю штат, и это лишняя денормализация, чтобы включить его снова.

Так что, если я знаю город, я знаю штат, и я знаю страну.

АДРЕС (id, адрес, city_fk), CITY (идентификатор, имя, штат ФК), STATE (идентификатор, имя, странаFK), СТРАНА (идентификатор, имя)

На практике существуют законные аргументы в пользу того, чтобы сделать город сущностью или атрибутом. Для чего-то вроде почтового адреса, вероятно, проще сделать его атрибутом.

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

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

Теперь возьмем, к примеру, Лейквуд в американском штате Огайо. Юрисдикция, Лейквуд - округ Кайахога. С точки зрения политической телевизионной рекламы, она является частью Области рынка телевидения Кливленда-Акрона-Кантона. Он находится недалеко от города Кливленд, который также является юрисдикцией округа Куйахога. Лейквуд разделен на четыре приходских совета, каждый из которых разделен на пятнадцать или более участков. Он является частью государственного дома Район 13, который включает Лейквуд и часть западной части города Кливленда. Он является частью штата Сенат округа 23, который включает в себя Бруклин, Брук Парк, Кливленд (округа 7-21 и часть округа 14), Лейквуд, Линдейл, Мидлбург-Хайтс, Парма и Парма-Хайтс. Лейквуд находится в 10-м округе США в штате Огайо (представлен Денисом Кусиничем).

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

Answer 7

Зависит от того, как вы определили PrimaryKeys для всех таблиц. Если у вас есть столбец id в качестве ключа для всех таблиц, вы можете уменьшить столбцы во всех таблицах, чтобы они просто сохраняли FK для следующего региона.

• address (ПОДАРОК)
• city через address.city_fk
• state через city.state_fk
• country через страну state.country_fk

Дизайн был бы как у Криса. Если вам нужны все данные в одном запросе, вы должны выполнить объединение.

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

• Страна 8 (Франция)
• Штат 3 (Париж-регион)
• Город 23 (Париж)
• Адрес 1 (первый адрес, сохраненный для этого города)

Недостаточно просто знать, что «Город 23», потому что тогда возникает вопрос: 23-й город в КАКОМ штате, и какой штат в КАКОЙ стране - это заставит вас хранить данные во всех таблицах.

Но это действительно зависит от того, как вы определили свои ключи.

Answer 8

Я бы сделал это:

• Страна (countryID, countryName)
• State (stateID, stateName, countryID (FK))
• Город (cityID, cityName, stateID (FK)) <- вы переносите страну с этим FK </li>
• Адрес (addressID, adressDescription, cityID) <- та же концепция, что и здесь. </li>

Теперь скажите мне, каковы шансы иметь один и тот же адрес в разных городах, штатах, странах? Минимально. Так что это должно работать. Помните, что нормализация БД до предела не всегда работает или полезна.

Надеюсь, это поможет

С наилучшими пожеланиями!