實體框架繼承:TPT,TPH還是沒有?

entity-framework inheritance

我目前正在閱讀有關在Entity Framework中使用繼承的可能性。有時我使用approch鍵入數據記錄,我不確定是否會使用TPT或TPH或者沒有...

例如......我有一個電子商務商店,它增加了運費,賬單和送貨地址

我有一個地址表:

RecordID
AddressTypeID
Street
ZipCode
City
Country

和一個表AddressType

RecordID
AddressTypeDescription

當人們展示TPT或TPH時,桌子設計與通用設計不同......當有這樣的方法時,考慮繼承是否有意義..

我希望它有意義......

謝謝你的幫助...

一般承認的答案

你應該看看我的EF提示系列

名為“ 如何選擇繼承策略”的那個應該會給你更多的見解

希望這可以幫助

亞歷克斯


熱門答案

在考慮如何在數據庫中表示繼承時,您需要考慮一些事情。

如果你有許多不同的子類,你可以在涉及那些可能損害性能的更複雜類型的查詢中有很多額外的連接。 TPH的一大優勢是,您可以在一個表中查詢層次結構中的所有類型,這對性能尤其有利,特別是對於較大的層次結構。出於這個原因,我傾向於在大多數情景中採用這種方法

但是,TPH意味著您不能再為子類型提供NOT NULL字段,因為所有類型的所有字段都在一個表中,從而將數據完整性的責任推向了您的應用程序。雖然這在實踐中聽起來可怕但我沒有發現這是一個太大的限制。

但是,如果每種類型都有很多字段,並且層次結構中的類型數量可能很小,那麼我傾向於使用TPT,這意味著連接的性能不是很大,而且你會變得更好數據的完整性。

請注意,EF和其他ORM的一個優點是,您可以在不影響應用程序的情況下改變主意,因此決策不需要完全刻板。

在您的示例中,它似乎沒有繼承關係,從地址類型到地址看起來像一對多

這將在您的類之間表示如下:

Address.AddressType
AddressType.Addresses


許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因