Помощь со схемой базы данных (не зависит от платформы) - PullRequest
3 голосов
/ 31 августа 2010

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

В колледже я узнал о «рационализации» (я думаю, что это слово онииспользуется, может быть далеко) база данных и есть 5 уровней.Из того, что я помню, уровень 3 был самым распространенным.Я знаю, что практикой было следить за тем, чтобы данные не повторялись, и для этого нужно было разбивать таблицы на более мелкие.И в зависимости от того, как далеко вы его разбили, тем выше был уровень.Ну, я не знаю, хочу ли я наивысшего уровня, но я знаю, что хочу, чтобы он был настолько эффективным, насколько я могу его получить.У меня было 4 года на SQL Server 2000/2005/2008 и 2 года на Oracle, около 6 месяцев с Informix (5+ лет назад), здесь или там с MySQL и около 6 месяцев доступа.Я предпочитаю SQL Server, но я хотел бы, чтобы схема была максимально эффективной на любой платформе.

Вот схема схемы psuedo для некоторых таблиц, затем я объясню, что я хочу сделать.

Manufacturers
  ManufacturerID (Identity)
  ManufacturerName
  ManufacturerStreetAddress
  ManufacturerZipCodeID
  ...

ZipCodes
  ZipCodeID (Identity)
  ZipCode
  ZipCodeStateID
  ...

States
  StateID (Identity)
  StateName
  StateAbbreviation
  ...

Cities
  CityID (Identity)
  CityName
  CityStateID
  ...

Я извиняюсь за то, что это только схема псевдо, но это все, что у меня есть сейчас, так как я делаю дизайн на бумаге в перерыве, но у меня был вопрос, прежде чем я зашел слишком далеко.Что я хочу сделать, так это убедиться, что все правильно связано друг с другом.Я считаю, что почтовый индекс принадлежит штату и городу, но ни один город не принадлежит ни одному единственному почтовому индексу, их может быть много.Если я добавлю почтовый индекс в таблицу производителей, я хочу получить название штата и города.Но я не хочу использовать идентификаторы слишком много раз в других таблицах.Я имею в виду, что StateID в ZipCodes и Cities может быть слишком много раз.В штате может быть несколько городов с одинаковыми именами, а в нескольких штатах могут быть города с одинаковыми именами.Но я не уверен, что мне нужна таблица CityNames, а затем таблица CityStates (CityNameID и StateID).Я хорошо знаю, что есть базы данных местоположения для покупки, может быть, некоторые бесплатные, которые я мог бы использовать, и мне не пришлось бы об этом беспокоиться.Тем не менее, я хотел бы поработать над моим пониманием этого, потому что я считаю, что это поможет мне в разработке схемы в будущем, а также потому, что я хотел бы иметь удобство компоновки, если нужно что-то изменить.

Вопросы:

  1. Кажется ли эта схема псевдо, как она есть, правильной или лучше (мнение)?
  2. Называется ли она "рационализацией" базы данных, иличто-то еще (проголосует за правильный ответ)?И как далеко слишком далеко (мнение)
  3. Также будет таблица Users и другие таблицы, которые будут включать адреса (команды, капиталы и т. Д.), Как и схема psuedo, если она верна вТеория, будь хорошим планом для такой базы данных (мнение)?

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

Обновление : Кроме того, я забыл упомянуть, что при "рационализации" базы данных возникает необходимость в объединениях, а иногда и в подзапросах.Я обычно злоупотребляю ЛЕВЫМИ НАРУЖНЫМИ СОЕДИНЕНИЯМИ, но какой самый эффективный способ связать эти таблицы для отображения адреса, а не выполнять 4 разных запроса?Спасибо.

Обновление : Хорошо, теперь это может быть слишком нормализовано или недостаточно нормализовано или вообще, но не могли бы вы, ребята, сказать мне, если вам нравится эта схема псевдо?

Manufacturers
  ManufacturerID (Identity)
  ManufacturerName
  ManufacturerStreetAddress
  ManufacturerCCSZID --CCSZ (Country, City, State, Zip), needs a better name
  ...

ZipCodes
  ZipCodeID (Identity)
  ZipCode
  ...

States
  StateID (Identity)
  StateName
  StateAbbreviation
  ...

Cities
  CityID (Identity)
  CityName
  ...

Countries
  CountryID (Identity)
  CountryName
  CountryAbbreviation
  ...

CountryCityStateZipCodes
  CountryCityStateZipCodeID (Identity)
  CCSZCountryID
  CCSZStateID
  CCSZCityID
  CCSZZipCodeID

А чтобы получить адрес, он бы выглядел так:

SELECT  M.ManufacturerStreetAddress,
        CN.CountryName,
        CN.CountryAbbreviation,
        S.StateName,
        S.StateAbbreviation,
        C.CityName,
        Z.ZipCode
FROM Manufacturers M
LEFT OUTER JOIN CountryCityStateZipCodes CCSZ ON CCSZ.CountryCityStateZipCodeID = M.ManufacturerCCSZID
LEFT OUTER JOIN Countries CN ON CN.CountryID = CCSZ.CCSZCountryID
LEFT OUTER JOIN States S ON S.StateID = CCSZ.CCSZStateID
LEFT OUTER JOIN Cities C ON C.CityID = CCSZ.CCSZCityID
LEFT OUTER JOIN ZipCodes Z ON Z.ZipCodeID = CCSZ.CCSZZipCodeID

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

Ответы [ 3 ]

3 голосов
/ 31 августа 2010

Я всегда слышал, что это называется "нормализация", но мы говорим об одном и том же.

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

  1. Северо-восточные штаты имеют почтовые индексы которые начинаются с 0, который будет усеченный, если вы делаете почтовый индекс числовое поле.
  2. Если вы используете почтовый индекс в качестве ключа, вы не можете иметь этот почтовый индекс в нескольких раз для нескольких городов. Как ты сказал, что почтовое отделение заботится больше о молнии, чем название города. Но эта установка будет ограничивать вас от поиска тех лиц Города позже.

Чтобы выполнить поиск по городу, штату или почтовому индексу позже, просто присоедините эту таблицу к таблице производителей. Вы в порядке, используя INNER JOIN - если в таблице Manufacturers нет полей, где ManufacturerZipCodeID не заполнено, в этом случае вы захотите, чтобы LEFT JOIN также отображал их.

1 голос
/ 31 августа 2010

Я не эксперт по базам данных, но, с моей точки зрения, данная псевдо-схема представляется неверной. Вот объяснение. Факты, известные из проблем:

  1. В штате может быть несколько городов.
  2. Состояние уникально
  3. Города могут иметь несколько почтовых индексов
  4. Название города может быть равно названию другого города.
  5. Почтовый индекс является уникальным

Сначала запишите уникальность. Итак, мы построим эти две необработанные таблицы:

STATE
---
State ID (PK)
State Name

ZIP
---
Zip ID (PK)
Zip Code (NK)

Тогда возникает логичный вопрос. Зная Zip ID, как бы мы получили City ID? Чтобы ответить на него, нам нужно указать связь между Zip и City. Где должна быть указана эта ссылка? Его нет в таблице City, поскольку из факта № 3 мы знаем, что в городе может быть много разных почтовых индексов. Так должно быть в ZIP-таблице. Это наша следующая версия таблицы ZIP:

ZIP
---
Zip ID (PK)
Zip Code (NK)
City ID (FK)

Теперь, поскольку мы можем «переместиться» из Zip в City, мы поговорим о таблице City. Название города может иметь то же имя, что и другие. Поэтому нам не нужно заставлять его (поле названия города) быть уникальным. Итак, это наша первая версия таблицы City:

CITY
----
City ID (PK)
City Name

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

CITY
---
City ID (PK)
City Name
State ID (FK)

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

Рационализация базы данных хороша с точки зрения базы данных, но может рассматриваться как "зло" с точки зрения программирования. Потому что это подталкивает программиста писать все больше и больше классов. В конце концов, «слишком далеко» можно определить как «таблица становится иррациональной». Таблица названий городов кажется иррациональной, поскольку это атрибут, а не сущность. Я с радостью назову «слишком далеко», если мой Database Analyst создаст такую ​​иррациональную таблицу :) С другой стороны, чрезмерная рационализация базы данных может сильно повлиять на производительность базы данных. По моему опыту, это заставляет запрос выполняться медленнее.

По поводу других проблем, таких как Пользователи, Команды, Капитолий и т. Д. Я пока не могу ничего сказать, поскольку еще не видел проблемы.

1 голос
/ 31 августа 2010

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

Вы собираетесь сделатьмного объединений, сохраняя штат, город и почтовый индекс в отдельных таблицах, но имея дело с базами данных, в которых хранятся адреса без мер согласованности, это гораздо больше кошмар, чем несколько объединений.Например, вы получите «NY», «ny», «Ny», «New York» и «NewYork».Поэтому я думаю, что есть отдельная таблица для штата, города и почтовых индексов, которые в конечном итоге окупятся.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...