我有一组表与孩子的孩子，像这样：外键是否需要出现在孩子的孩子身上？
客户端（PK客户端ID），这是父（一对多）到
地产（PK物业ID，FK客户端ID），这是父（一对多）至
属性详细信息（PK PropDetailID，FK PropertyID）和Case（PK CaseID，FK PropertyID）。
父表的外键是否应该进一步重复下去？也就是说，应该我的表是这样的：
客户端（PK客户端ID）
地产（PK物业ID，FK客户端ID）
PropertyDetail（PK PropDetailID，FK物业ID，FK客户端ID）
Case（PK CaseID，FK PropertyID，FK ClientID）
取而代之？如果两个设置都没有标准化，那么这样做的标准化方式是什么？
不，不应该重复外键，因为您可以通过简单的连接来访问这些信息。将它添加到孙子们会增加冗余，当两者不同步时可能会产生问题。你的第一个设计比你的第二个设计好看。
根据单词property的含义，可能是因为您正在使用entity attribute value（EAV）模型来存储客户端属性。在某些情况下，EAV模型是合适的，但一般情况下您应该尽量避免。如果可能，请尝试使用固定模式。
延伸阅读：
'物业'包括物业地址和一些额外的独特信息（如购买日期）。 “PropertyDetail”表可能是EAV模型 - 它基于外部密钥，由县分配的房产ID号。一个'Property'可能包含0到600个这些县ID号码，所以'PropertyDetail'将它们连接到'Property'，但是避免了主Property属性表中的空值。也许这是错误的方法？ （另外 - 县的ID是唯一的，但是16位数似乎会在索引编制时被谋杀。） – 2010-09-17 20:37:56
@ user450957：如果您有大量的属性，并且其中大多数通常是NULL，那么这是EAV可以适当。 – 2010-09-17 20:40:26
您不需要同时具有PropertyDetail/Case的外键。这些可以导航到。
有没有必要有外键重复进一步下跌 - 你可以通过查看该物业的客户端ID确定物业资料的客户端ID。
您需要的所有信息都可以通过简单的连接来确定。
谢谢！如果我被允许，我会赞成你们所有人。 – 2010-09-17 23:03:46