您应该规范化存储在数据库中的地址吗？答案

【问题标题】：Addresses stored in a database should you normalize?您应该规范化存储在数据库中的地址吗？
【发布时间】：2016-04-27 13:31:34
【问题描述】：

快速提问。

考虑下表（英国）：

您会将地址拆分到另一个表中吗？基本的业务假设是客户不能拥有多个地址。

最初我把它分开，看起来像这样：

客户表

地址表

邮编表：

城市表

除非我的假设是错误的，即邮政编码唯一地标识了街道名称和城市，这不在 3NF 中吗？

【问题讨论】：

【解决方案1】：

就个人而言，我会将地址放在另一个表中，并将它们链接在一起。

业务假设/规则可能会发生变化，当您拆分这些内容时，您最有可能在不进行重大重做的情况下适应任何可能的业务规则。

例如 - 哎呀，客户的帐单邮寄地址与他们的送货地址不同，或者哎呀，即使客户今年更改了地址，我们也需要知道去年实际发货的地点，等等。

【讨论】：

【解决方案2】：

基本的业务假设是客户不能拥有超过一个地址。

如果这是一个实际规则而不是假设，我会把它们放在一个表中。

但是，假设将 'ass' 放在 'u' 和 'me' 中。

所以请放心，将地址分散到另一个表中。但看起来你的规范化与你的示例相比太过分了。

【讨论】：

太好了，谢谢。所以你建议只用 Customer,name,Address 做一个表，而不是把它分开？
只有当你确定每个客户只能有1个并且不会改变时。但我确实说过要安全起见，把它放在单独的桌子上。
地址变了为什么还要单独的表？肯定会在客户表中更新？
您想要跟踪。例如，我 3 年前下的订单在哪里交付？如果你只是在更改时覆盖，你不会知道。
我明白你的意思。但我认为这不是我正在制作的数据库的要求。也许我应该先说我在做什么，哈哈！！基本上它是一个汽车租赁数据库，所以产品总是会被退回，我假设的系统只需要跟踪租用它的人，而不是它被租到的地址。

【解决方案3】：

是的，我会将地址拆分到一个单独的表中。

然而，原因不是规范化本身（在大多数情况下）。主要原因是它是一个缓慢变化的维度，查找以前的地址可能很有用。

您是否继续对邮政编码等内容进行规范化是个人喜好问题。在更“业余”的数据库中，我认为没有必要。但是，对于真实客户的大型数据库，我倾向于将其拆分。它有助于确保邮政编码准确无误。此外，它们会随着时间而变化。而且，您可能会购买邮政编码级别的其他信息。

【讨论】：

【解决方案4】：

这完全取决于您的要求，但正如您在上面提到的，客户不能拥有多个地址，因此无需另一个一对一关系，因为您可以将其放在同一个关系中。但我建议你将它分解成另一个一对多的关系，因为未来的需要。

【讨论】：