.net 在继承的实体（TPH）中映射导航属性

我有以下数据库架构：

我正在使用表层次结构（TPH）继承。案例表的“类型”字段确定案例是电子邮件案例还是twitter案例。它们都是与Cases表的1:N关系

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

问题是我无法使用外键（Email.CaseId Cases.Id和Tweets.CaseId Cases.Id）将导航属性映射到子表中。我想要实现的是，EmailCase实体有一个指向电子邮件的导航属性，TwitterCase实体有一个指向Tweets的导航属性

我可以让它工作，只有我添加了关联，然后手动导航，但当然这不会反映在数据库中

我怎样才能解决这个问题？我应该使用每类型表（TPT）而不是TPH吗？但在这种情况下，例如，EmailCase只包含原始案例的ID，没有其他对我来说听起来很奇怪的东西。（如果我使用模型优先的方法，将生成此结果。）

---

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

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

• 您的模型非常适合TPH，因为所有属性都在基类中，而派生类不向表中添加任何属性。因此，对这三个实体的所有查询（如果

  Cases

  是抽象的，则为两个）只需要此表，并且不涉及连接->有利于性能。另一方面，数据库会允许您的模型不一致，比如有一个

  电子邮件
  记录，其中
  案例Id
  =1引用了一个
  案例
  记录，该
  Id
  =1，但是
  类型
  鉴别器是一个
  TwitterCase
  。如果您仅使用EF访问数据库，则如果EF正确执行其工作，则永远不会发生这种情况。如果您有其他可能更改数据库的源，则可能会发生这种情况
  

• TPT将解决可能存在的模型不一致的问题，因为

  Emails

  表中的

  CaseId

  将引用

  EmailCases

  表，而

  Tweets

  表中的

  CaseId

  将引用

  TwitterCases

  表。但代价是这些奇怪的表只包含主键的一列，而每个查询（无论多么简单）都将涉及

  Cases

  表和派生类型的表之间的连接->对性能有害

---

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

谢谢您的回答。我有多种服务来收集来自不同来源的数据。所有这些服务以及使用EF与DB交互的web应用程序（ASP.NET MVC）。服务从源获取数据后，将其插入数据库，并从中创建案例。根据您的回答，我认为我将坚持使用TPH（据我所知，这意味着手动添加关联和导航到继承的实体）。@norbip：是的，我认为，一旦涉及继承，您就必须手动调整从数据库创建的模型。即使对于TPT：如果数据库中的

EmailCases

和

TwitterCases

表对

Cases

表具有FK约束，DB First可能会创建三个实体，它们之间具有导航属性，而不是层次结构。数据库不理解什么是继承。