实体框架继承：TPT、TPH 还是没有？答案

【问题标题】：Entity Framework inheritance: TPT, TPH or none?实体框架继承：TPT、TPH 还是没有？
【发布时间】：2009-05-30 15:27:58
【问题描述】：

我目前正在阅读有关在实体框架中使用继承的可能性。有时我使用一种方法来键入数据记录，但我不确定是否会使用 TPT 或 TPH 或不使用...

例如... 我有一个电子商务商店，它添加了送货、账单和送货地址

我有一个地址表：

RecordID
AddressTypeID
Street
ZipCode
City
Country

还有一张桌子AddressType

RecordID
AddressTypeDescription

当人们炫耀 TPT 或 TPH 时，表格设计与一般设计不同...... 当有这样的方法时考虑继承是否有意义..

我希望这是有道理的......

感谢您的帮助...

【问题讨论】：

【解决方案1】：

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

如果您有许多不同的子类，您可以在涉及那些可能会损害性能的更复杂类型的查询中进行大量额外的连接。 TPH 的一大优势是您可以在一个表中查询层次结构中的所有类型，这对性能有好处，尤其是对于较大的层次结构。出于这个原因，我倾向于在大多数情况下使用这种方法

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

但是，如果每种类型都有很多字段并且层次结构中的类型数量可能很少，我会倾向于使用 TPT，这意味着连接的性能不是那么大的问题，并且您可以获得更好的数据完整性。

请注意，EF 和其他 ORM 的优势之一是您可以在不影响应用程序的情况下改变主意，因此无需完全铁板一块地做出决定。

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

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

Address.AddressType
AddressType.Addresses

【讨论】：

【解决方案2】：

正如 Keith 所暗示的，这个 article 建议 EF 中的 TPT 非常糟糕，但我自己还没有尝试过。

【讨论】：

如果您从链接中提取相关详细信息到此答案，那就太好了，该链接将来可能会被删除/移动。
作为一个严格的轶事说明，我有一段时间使用 TPT 的项目，性能很糟糕，所以我正在经历迁移到 TPH 的痛苦。我遇到的查询性能问题严格来说是 EF，而不是 SQL； EF 的查询编译器似乎对 SQL 可以快速完成的某些事情感到窒息。尽可能使用 TPH 来避免这种情况。我一直在等待 EF 改进其查询编译时间。