实体框架继承:TPT,TPH还是没有？

Question

我目前正在阅读有关在Entity Framework中使用继承的可能性.有时我使用approch键入数据记录,我不确定是否会使用TPT或TPH或者没有...

例如......我有一个电子商务商店,它增加了运费,账单和送货地址

我有一个地址表:

RecordID
AddressTypeID
Street
ZipCode
City
Country

和一张桌子 AddressType

RecordID
AddressTypeDescription

当人们展示TPT或TPH时,桌子设计与通用设计不同......当有这样的方法时,考虑继承是否有意义..

我希望它有意义......

谢谢你的帮助...

Answer 1

你应该看看我的EF提示系列.

名为" 如何选择继承策略"的那个应该会给你更多的见解

希望这可以帮助

亚历克斯

Answer 2

在考虑如何在数据库中表示继承时,您需要考虑一些事情.

如果你有许多不同的子类,你可以在涉及那些可能损害性能的更复杂类型的查询中有很多额外的连接.TPH的一大优势是,您可以在一个表中查询层次结构中的所有类型,这对性能尤其有利,特别是对于较大的层次结构.出于这个原因,我倾向于在大多数情景中采用这种方法

但是,TPH意味着您不能再拥有NOT NULL子类型的字段,因为所有类型的所有字段都在一个表中,从而将数据完整性的责任推向了您的应用程序.虽然这在实践中听起来可怕但我没有发现这是一个太大的限制.

但是,如果每种类型都有很多字段,并且层次结构中的类型数量可能很小,我会倾向于使用TPT,这意味着连接的性能不是很大,而且你会变得更好数据的完整性.

请注意,EF和其他ORM的一个优点是,您可以在不影响应用程序的情况下改变主意,因此决策不需要完全刻板.

在您的示例中,它似乎没有继承关系,从地址类型到地址看起来像一对多

这将在您的类之间表示如下:

Address.AddressType
AddressType.Addresses

Answer 3

正如Keith所暗示的那样，本文建议EF中的TPT进行可怕的缩放，但我自己还没有尝试过。