何时将列分隔成新表

Question

我有公司，客户，供应商等表，它们都有地址信息相关的列。

我试图找出我是否应该创建新表的地址“和独立的地址都列了这一点。

在所有表格上都有地址列很容易使用和查询，但我不确定从一个好的设计角度来看它是否是正确的方式，将这些相同的列重复在几张表上让我好奇。地址

内容是不是对我很重要，我不会检查或使用上的任何决策过程决定这些地址，他们是纯粹的相关信息。目前，我在看有地址信息

Answer 1

所有设计问题的答案是这样的：

这取决于。

所以基本上，在地址的情况下，它取决于你是否有超过1个地址每个客户。如果您将多于1个，请将其放入新的地址表中，并为每个地址分配一个CustomerID。这是过度杀伤（大多数时候，这取决于！）来创建一个通用地址表并将其映射到公司/客户/供应商表。

它也往往矫枉过正（和危险）在你的对象之间的许多一对多的关系映射地址（如地址似乎可以幻化的用户，如果你这样做）。

一个大的规则是：保持简单！

Answer 2

如果你只使用自己的表的范围内，这些地址5桌，有可能是没有真正的好处将它们转移到自己的表。

基本上，这听起来不像是值得的努力。

Answer 3

是的，您应该将地址分隔到自己的表中。知道要问这件事很明智。这里的关键是地址的一般格式是相同的，不管它是谁;客户，公司，供应商......他们都有相同的地址字段。

这样做的价值在于将地址视为原子元素的能力;也就是说，您可以概括所有与地址相关的功能，并只处理一个表，而不用担心它处理多个表，以及可能发生的相关模式漂移。

Answer 4

如果有表之间（在公司和供应商表都进入即同一组织）的重叠，而地址应该永远是两个表中是相同的，那么它可能是值得关在其自己的表移动地址并从其他三张表中获得外键。这样，你只需要在一个地方更新它就可以了。

如果三个表是彼此完全独立的，那么就没有真正太多从数据移动到另一个表来获得，所以你还不如不要管它。

Answer 5

这被称为Database Normalization。是的，如果没有其他原因，您希望将它们分开，因为如果您将来需要使用代码和查询时会更困难。

作为一项规则，您应该始终以第三范式设计您的数据库，即使对于简单的应用程序（在少数情况下，您不会出于性能或物流原因，但开始时我总是试图使它是第三范式，然后在知道正确的做法之后学会作弊）。

编辑：为了扩大这一点，并添加了一些我在其他人的帖子上发表的评论，我认为当谈到代码和重构它时，复杂和更深入的面向对象的原则将是适当的。但是，重构正在生产的数据库并不那么简单。这都是关于投资回报。从一开始就设计规范化的数据库非常容易，以证明不这样做。设计不佳的数据库的后果可能是灾难性的，通常来不及实现这一目标。

Answer 6

我认为这完全取决于数据库的用途。无可否认，所有的地址信息在结构上都是相同的，并且从理论的观点来看，所有的地址信息都应该位于通过密钥从父表格链接的单个表格中。

但是从性能和查询的角度来看，将它们保留在它们各自的表中的确从报告的角度简化了事情。

我有我目前的公司[物流]其中的地址实际上是逻辑上是相同的情况 - 他们的所有位置，无论他们是否是取货地点，交货地点，客户等

在我的情况，我会说他们绝对应该放在一张桌子上。但是，如果从供应商，客户，联系信息的角度来看它，我会说理论上在一张表中有地址是很好的，但实际上它不会给你一大堆，因为数据不太可能重复。

Answer 7

我不同意戴夫。多对多的方法（地址< - >用户）既安全又非常有利。

当客户移动时，地址表中的地址不会改变。而是在地址表中找到新地址，并将客户等链接到该记录。如果新地址不在表格中，则将其添加到表格中。

那么地址记录本身有没有改变？是的，在这样的情况下：

• 事实证明地址有一个错字
• 美国邮政服务的更改街道名称

这些都是非常情况下把所有的地址在一个表没有重复的回报;任何其他安排都需要一个恼人的重复数据输入。

当然，如果数据库被滥用，那么避免多对多关系会更安全。但是通过这个标记，如果数据库处于不利的状态，最好将所有内容打印出来，存储在文件柜中，然后根据纸张副本验证每笔交易。所以在我看来，“防止滥用”并不是一个好的设计原则。