我有一組表與孩子的孩子，像這樣：外鍵是否需要出現在孩子的孩子身上？
客戶端（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