考慮這個簡單的設定。
在此模型中，適用以下限制：
- 一個人要么是父母，要么是孩子。
- 每個孩子只有一位家長
- 父級與公用事業實體有關系
由于父母，孩子與效用具有傳遞關系。
現在，問題是：每個孩子都應該在資料庫中設定“City utility id”屬性嗎？
優點：您避免了可空性。據說如果該欄位可以為空，則資料庫將構建效率較低的索引，因為每個作為孩子的人都將在此屬性上具有相同的值（null）。
缺點：不太干凈，對 CUD 操作的記賬更多。該欄位不傳達尚未在資料庫中表示的資料。
uj5u.com熱心網友回復：
EF 支持按層次結構表 (TPH) 和按具體型別表 (TPT)，因此就架構而言，您可以選擇。雖然父母和孩子都“是”人，但他們每個人都有各自的特征。其中一個是只有父母分配了城市公用事業，其他是孩子只能與父母相關聯。（父不能參考另一個父作為子，或者子不能參考另一個子作為父。）在單個表中處理所有這些場景是一個 TPH 結構，它依賴于應用程式代碼強制執行的隱式規則，并且導致許多可空參考和適用于其中一個或另一個的資料的欄位。
我建議盡可能使用 TPT 結構并使關系更加明確。這樣做的好處是不完全依賴應用程式代碼來確保在資料庫級別強制執行關系和“可選性與必需性”。
這將是這樣的：
[Person]
PersonId [PK]
// other common fields that apply to ALL types of Person.
[Parent]
PersonId [PK, FK]
CityUtilityId [FK]
// other parent-specific fields.
[Child]
PersonId [PK, FK]
ParentPersonId [FK] (To Parent, not Person)
// other child-specific fields.
這樣，如果父項或子項具有必需或可選欄位，則可以將它們放入各自的表中，并具有各自的 NULL 能力。另一種方法是該欄位始終可以為 NULL，并且由應用程式來確保強制執行其中一個或另一個所需的性質。資料庫可以在任何時候錯誤地進入完全無效的狀態而無需投訴。
開發社區仍然有很多吸引力，以盡量減少表的數量，這主要源于驅動器空間昂貴且架構成本 $$ 的日子，因此將類似的資料組合到單個表中可能是有意義的。盡管它仍然有明顯的缺點。對于現代資料庫，我認為只組合有效相同的內容并使用 TPT 進行繼承或使用組合總是更好。
組合的一個例子是類似具有狀態的訂單。該狀態可能是已交付，并且可能有我們希望在交付時針對訂單記錄的詳細資訊。（簽名等）這些可能是 Order 表上的 Null 欄位，但它們僅適用于 Delivered 訂單，在所有其他情況下均為 Null。相反，有一個像 OrderDeliveryDetails /wa 與訂單的一對一關系的表，它是在交付訂單時創建的。（如果訂單出于任何原因從已交付狀態更改為其他狀態，則洗掉/無效。）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/520389.html
上一篇：在MySQL中使用子查詢設定AutoIncrement值
下一篇：如何從自聯接表中檢索空值