昨天我注意到详细信息表中的一个外键列直接链接到一个customer表。这个详细信息表只是一个来自客户的标题表删除的连接，它已经是客户的正确外键和详细信息，请耐心等待。
[Cust] ---< [Header] ---< [Detail]
| V
|________ wtf? ____________|
ASCII数据库建模密钥：
V
---< = 1 to many, and _| also = 1 to many
当我按下桌面设计师的问题时，他通过解释他将使用此栏保存加入通话来为其辩护......
IMO这样可以节省一个缓慢输入，懒惰的SQL编写器，而不必以非规范化模式的价格加入一个额外的表。 （此示例中哪些正常形式直接失败？）
即使使用这样的概念节省了十几个连接，它还 值得吗？
答案 0 :(得分：2)
是否遇到了通过添加适当的索引无法解决的实际性能问题？
如果没有，那么引入这样的“周期”可能会在某些情况下导致数据冲突，我会避免。
答案 1 :(得分：1)
是。消除连接可能会影响性能;直接支持运行得足够快的用户界面以使该界面可用的查询是一个优于设计纯度的考虑因素。
虽然在维护规范化的核心模式和一组汇总表之间存在一种分区，但要从核心表中提供，然后再支持UI。
答案 2 :(得分：1)
这是'依赖'的经典答案 - 一种尺寸并不适合所有人，你所看到的是纯粹的学术方法与实用方法之间的永恒平衡。在任何一个方向上太远都会产生不好的结果，所以有时你会牺牲学术上的正确性来使事情顺利进行。
在不知道工作量，查询数量，优化等结果将/不会使用的频率等情况下，无法确定此案例是过早优化还是有效案例。
答案 3 :(得分：1)
即使使用这样的概念节省了十几个连接，它是否值得呢？
数据库设计人员/数据建模人员的正确答案是，有些情况下，CUSTOMER记录可能与DETAIL记录无关，而且没有支持HEADER记录，规则。
添加外键是为了破坏数据模型，允许不良数据。如果只有一个DETAIL记录与CUSTOMER相关联，那么我希望HEADER表中的单个记录 - 这是一个corrollary / xref / lookup表的点，允许支持0+的记录。它也使查询保持一致 - 这一切都不是“今晚的月亮是什么房子？”惨败导致众多疑问......
答案 4 :(得分：0)
“来自数据库设计人员/数据建模人员的正确答案是，根据业务规则，有些情况下CUSTOMER记录可能与没有支持HEADER记录的DETAIL记录相关。”
非常清楚地表明两种关系都是一对多的，所以没有支持HEADER记录的DETAIL记录是不可能的。
但可能的是，细节中的某些内容与另一位客户相关，而不是遵循HEADER / CUSTOMER“路径”时发现的内容。尽管可能不太可能，但只有定义架构的人才能回答这个问题。
答案 5 :(得分：0)
不知道您的表结构，我将指出向多个子表添加客户ID是一种常见的非规范化。根据你的说法，他把它作为外键，所以没有风险这样做，并且有很多潜在的性能优势。
只要头表中还有一个外键，我就会发现设计没什么问题。
有经验的数据库人员知道将针对表写入的查询类型，可以在设计时看到其中一些非规范化。可能如果我有多个客户，我希望能够通过客户查询详细信息表，而无需多次通过标题表。这当然取决于头表中是否有我在查询中需要的信息。在这里，我们可以选择根据哪个是特定查询的更好选择，并且所有约束都已到位以防止数据完整性问题。而我们花费的只是额外的磁盘空间。