我有公司、客户、供应商等表，它们都有地址信息相关的列。
我想弄清楚是否应该创建一个新表“地址”并将所有地址列分开。
在所有表上都有地址列很容易使用和查询，但从良好的设计角度来看，我不确定这是否是正确的做法，让这些相同的列在几个表上重复让我很好奇。
地址的内容对我来说并不重要，我不会在任何决策过程中检查或使用这些地址，它们纯粹是与信息相关的。目前我正在查看 5 个包含地址信息的表
【问题讨论】：
标签： asp.net sql performance design-patterns
所有设计问题的答案是这样的：
视情况而定。
因此，基本上，在地址的情况下，这取决于您是否会为每位客户提供超过 1 个地址。如果您有超过 1 个，请将其放入新的 Addresses 表中，并为每个地址指定一个 CustomerID。创建通用地址表并将其映射到公司/客户/供应商表是过度的（大多数时候，这取决于！）。
在您的对象之间以多对多关系映射地址通常也有点矫枉过正（而且很危险）（因为如果您这样做，地址似乎会在用户身上神奇地改变）。
一个重要的规则是：保持简单！
【讨论】：
这称为Database Normalization。是的，如果没有其他原因，您想将它们分开，因为如果您将来需要，当您有代码和查询时会更加困难。
通常，您应该始终以第三范式设计您的数据库，即使对于简单的应用程序也是如此（在某些情况下，您不会出于性能或逻辑原因，但一开始我总是会尝试做到这一点第三范式，然后在你知道正确的做法后学会作弊）。
编辑：为了对此进行扩展并添加我在其他帖子中所做的一些 cmets，我坚信在涉及代码时从简单的设计开始，并在很明显变得过于复杂时进行重构更深入的面向对象原则将是合适的。但是，重构生产中的数据库并不是那么简单。这一切都与投资回报率有关。从一开始就设计一个规范化的数据库来证明不这样做太容易了。设计不佳的数据库的后果可能是灾难性的，在您意识到这一点之前通常为时已晚。
【讨论】：
是的，您应该将地址分开到自己的表格中。知道问是件聪明的事。这里的关键是地址的一般格式是相同的，无论它是谁；客户、公司、供应商……他们都有相同的地址字段。
之所以值得这样做，是因为它能够将地址视为原子元素；也就是说，您可以概括与地址相关的所有功能并让它只处理一个表，而不必担心它处理多个表以及可能发生的相关架构漂移。
【讨论】：
如果您只在它们自己的表范围内使用这些地址，那么将它们移动到它们自己的表中可能没有真正的好处。
基本上，这听起来不值得。
【讨论】：
如果表之间存在重叠（即在公司表和供应商表中都输入了相同的组织），并且两个表中的地址应该始终相同，那么可能值得将地址移到自己的表中，并且从其他三个表中获得外键。这样，您只需在它发生变化时在一个地方更新它。
如果这三个表完全相互独立，那么将数据移动到另一个表并没有太大的好处，所以你还是不要管它。
【讨论】：
我认为这完全取决于数据库的用途。诚然，所有地址信息在结构上都是相同的，从理论上讲，它们都应该在一个通过键与父表链接的单个表中。
但是从性能和查询的角度来看，将它们保存在各自的表中确实从报告的角度简化了事情。
我目前的公司 [物流] 有一种情况，地址在逻辑上实际上是相同的 - 它们都是位置，无论它们是取货地点、送货地点、客户等。
就我而言，我会说他们绝对应该都在一张桌子上。但如果从供应商、客户、联系信息的角度来看，我会说虽然理论上将地址放在一个表中很好，但实际上它不会给你买很多东西，因为数据不太可能重复。
【讨论】：
我不同意戴夫的观点。多对多方法（地址 用户）既安全又非常有利。
当客户移动时，地址表中的地址不会改变。而是在地址表中找到新地址，并将客户等链接到该记录。如果新地址尚未在表中，则会将其添加到其中。
那么地址记录本身会改变吗？是的，在这样的情况下：
在这些情况下，将所有地址放在一个表中而不重复会得到回报；任何其他安排都需要烦人且重复的数据输入。
当然，如果数据库被滥用，那么避免多对多关系会更安全。但是从这个意义上说，如果数据库被坏人掌握，最好将所有内容打印出来，将其存储在文件柜中，并根据纸质副本验证每笔交易。因此，在我看来，“防止误用”并不是一个好的设计原则。
【讨论】：