外键是否需要出现在children的children中？答案

【问题标题】：Does a foreign key need to appear in children of children?外键是否需要出现在children的children中？
【发布时间】：2011-04-13 21:33:51
【问题描述】：

我有一组带有孩子的孩子的表格，如下所示：

客户端（PK ClientID）是父级（一对多）

属性（PK PropertyID，FK ClientID）是父（一对多）到

属性详细信息（PK PropDetailID，FK PropertyID）和案例（PK CaseID，FK PropertyID）。

是否应该进一步向下重复父表的外键？也就是说，我的表格应该是这样的：

客户（PK ClientID）

属性（PK PropertyID，FK 客户端 ID）

PropertyDetail（PK PropDetailID、FK PropertyID、FK 客户端 ID）

案例（PK CaseID、FK PropertyID、FK ClientID）

相反？如果两个设置都没有标准化，那么标准化的方法是什么？

【问题讨论】：

【解决方案1】：

不，不应重复外键，因为您可以通过简单的连接访问此信息。将其添加到孙子会增加冗余，当两者不同步时可能会出现问题。您的第一个设计看起来比第二个更好。

根据property 一词的含义，您可能正在使用entity attribute value (EAV) 模型来存储客户端属性。在某些情况下，EAV 模型是合适的，但通常您应该尽量避免使用它。如果可能，请尝试使用固定架构。

进一步阅读：

【讨论】：

Property 包括物业地址和一些额外的独特信息（如购买日期）。 PropertyDetail 表可能是 EAV 模型 - 它基于外部键，即县分配的属性 ID 号。 Property 可能包含 0 到 600 个这些县 ID 号，因此 PropertyDetail 将它们连接到 Property 但避免在主 Property 表中出现空值。也许这是错误的方法？（另外 - 县 ID 是唯一的，但 16 位数字在索引时似乎会被谋杀。）
@user450957：如果您有大量属性并且其中大多数通常为 NULL，那么这是适合 EAV 的场合之一。

【解决方案2】：

您不需要同时拥有 PropertyDetail/Case 的外键。这些可以导航到。

【讨论】：

【解决方案3】：

无需进一步重复外键 - 您可以通过查看属性的 ClientID 来确定属性详细信息的 ClientID。

您需要的所有信息都可以通过简单的连接来确定。

【讨论】：