在继承的entites（TPH）中映射导航属性

Question

我有以下数据库架构：

我正在使用Table-per-Hiearchy（TPH）继承。 Cases表的“类型”字段确定案例是电子邮件案例还是推特案例。它们都是与Cases表的1：N关系。

我正在使用EF的数据库优先方法，这是我想要使用的模型：

问题在于我无法使用外键（Email.CaseId＆lt; - ＆gt; Cases.Id和Tweets.CaseId＆lt; - ＆gt; Cases.Id）将导航属性映射到子表中。我想要实现的是，EmailCase实体具有电子邮件的导航属性，而TwitterCase实体有一个推文。

只有当我手动添加关联然后手动导航时才能使它工作，但当然这不会反映在数据库中。

我该如何解决这个问题？我应该使用Table-per-Type（TPT）而不是TPH吗？但在这种情况下，例如，EmailCase只包含原始案件的ID，对我来说没有其他任何听起来很奇怪的东西。 （如果我使用模型第一种方法，这将会生成。）

或者我应该手动添加关联和导航属性吗？

Answer 1

这很难回答，因为有两个明显的好处 - 一个投票给TPH，另一个投票给TPT：

• 您的模型非常适合TPH，因为所有属性都在基类中，派生类不会向表中添加任何属性。因此，对于三个实体（或两个，如果Cases是抽象的）的所有查询仅需要此表并且不涉及连接 - ＆gt;有利于表现。另一方面，数据库会允许您的模型出现不一致，例如Emails个CaseId条记录Cases = 1引用此Id = 1的Type条记录，但是TwitterCase鉴别符是CaseId。如果您只使用EF访问数据库，那么如果EF正确完成其工作，则不应发生这种情况。如果您有其他可能会更改数据库的来源，则可能会发生这种情况。

• TPT可以解决可能的模型不一致问题，因为Emails表中的EmailCases会引用CaseId表和Tweets TwitterCases 1}}表到Cases表。但是价格是你有这些奇怪的表只包含一个主键的列和每个查询 - 无论多么简单 - 将涉及{{1}}表和派生类型的表之间的连接 - ＆GT;对表现不利。

对您来说更重要的是什么？就个人而言，如果只有EF应用程序访问数据库，由于性能优势，我会稍微倾向于TPH。但是，如果不了解应用程序的整个上下文，我无法最终决定做什么。