Database design 协助数据库架构（独立于平台）

我有一个观点问题，但同时可能有一个正确的答案。我正在尝试开发一套产品，并希望确保，因为我自己在做，所以我第一次就做对了。我已经多次重写该模式，每次都认为它更好。然后我可能会遇到一些新的想法，它要么需要对模式进行大量的工作，要么会破坏我的模式

在大学里，我学到了数据库的“合理化”（我想这是他们用的词，可能有点离谱），共有5个级别。据我记忆所及，3级是最常见的。我知道这种做法是为了确保数据不会重复，要做到这一点，您必须将表拆分为更小的表。根据你打破它的程度，级别越高。嗯，我不知道我是否想要最高级别，但我知道我希望它尽可能地高效。我在SQL Server 2000/2005/2008上工作了4年，在Oracle上工作了2年，在Informix上工作了6个月（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
  ...

我为它只是一个psuedo模式而道歉，但这就是我现在所拥有的，因为我正在休息时做纸上设计，但在我走得太远之前有一个问题。我想做的是确保每件事都正确地联系在一起。我的信念是，一个邮政编码属于一个州和一个城市，但没有一个城市属于任何一个邮政编码，它可能有很多。如果我把邮政编码放在制造商表中，我希望能够得到州和城市。但我不想在其他表中多次使用任何ID。我的意思是，在ZipCodes和城市中拥有StateID的次数可能太多了。一个州可以有多个同名城市，多个州可以有同名城市。但我不确定是否需要一个CityNames表，然后是CityStates表（CityNameID和StateID）。我很清楚，有一些位置数据库可以购买，也许是一些免费的，我可以使用，也不必担心这一点。然而，我想进一步了解这一点，因为我相信这将有助于我在未来的模式设计，但也因为我希望在需要更改任何内容时，布局具有可定制性

问题:

这个psuedo模式看起来是正确的还是更好（观点）

这叫“合理化”数据库，还是其他什么（投票支持正确答案）？还有多远才算太远（意见）

还将有一个用户表，以及其他包含地址（团队、国会大厦等）的表，因此，如果psuedo模式在理论上是正确的，那么对于这样的数据库，它是否是一个好的计划（意见）

谢谢大家抽出时间，我将投票赞成任何彻底和连贯的答案。最好是数据库专家或有多年数据库经验的人，但我会听取所有答案。此外，我不确定这是否应该是一个社区维基，但我现在不把它标记为一个。谢谢

更新：另外，我忘了提到，我知道通过“合理化”数据库，需要连接，有时需要子查询。我通常会滥用左外部联接，但将这些表绑定在一起以显示地址，而不是执行4个不同的查询，最有效的方法是什么？谢谢

更新：好的，现在这可能是太规范化或不够规范化或根本没有，但你们能告诉我你们是否更喜欢这个psuedo模式吗

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

---

或者你们知道一个更好的方法来写这个查询。但不管怎样，这看起来比第一个模式好吗？

我一直听说它被称为“规范化”，但我们谈论的是同一件事

最简单的方法可能是将城市、州和zip合并到一个表中。您甚至可以考虑使用邮政编码本身作为密钥，尽管我可以想到两个原因，您希望避免这一点：

东北部各州有邮政编码 以0开头，它将是 如果您将邮政编码设为 数值场

如果使用邮政编码作为密钥，则不能将该邮政编码包含在多个邮政编码中 多个城镇的时间。像你一样 他说，邮局更关心 关于拉链，而不是城镇名称。 但是这个设置会限制你 从那些人身上搜出来的 稍后再来

---

以后要按城市、州或邮政编码进行搜索，只需将此表连接到Manufacturers表。您可以使用内部联接-除非Manufacturer表中有ManufacturerZipCodeID为空的字段，在这种情况下，您需要一个左联接来显示这些字段。

我对设置内容的方式没有太大问题。邮政编码中的州ID可能很危险——如果知道有跨越州边界的邮政编码，我不会感到惊讶，但我不确定这一点

---

您将通过在单独的表中存储state、city和zip代码来进行大量连接，但是在处理存储地址而没有一致性度量的数据库之后，这比几个连接更像是一场噩梦。例如，你以“NY”和“NY”和“NY”以及“纽约”和“纽约”结尾。因此，我认为为state、city和zips单独设置一个表从长远来看会有回报。

我不是数据库专家，但在我看来，给定的伪模式似乎是不正确的。这是解释。从问题中了解到的事实是：

一个州可以有多个城市

一个国家是独一无二的

一个城市可以有多个邮政编码

城市名称可能等于另一个城市名称

邮政编码是唯一的

首先，写下单号。

STATE
---
State ID (PK)
State Name

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

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

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

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