映射导航属性

Question

我有以下数据库模式：

我使用表每次Hiearchy（TPH）的继承。 “案例”表的“类型”字段确定案例是电子邮件案例还是叽叽喳喳案例。它们都是与Cases表的1：N关系。

我使用数据库先用EF办法，这就是我要使用的模型：

的问题是，我无法使用外键导航属性映射到子表， （Email.CaseId < - > Cases.Id和Tweets.CaseId < - > Cases.Id）。我想要实现的是EmailCase实体具有导航属性来发送电子邮件，而TwitterCase实体具有一个Tweets。

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

我该如何解决这个问题？我应该使用Table-per-Type（TPT）而不是TPH吗？但在这种情况下，例如EmailCase只会包含一个ID到原来的情况，没有别的，这听起来很奇怪。 （这是如果我使用模型第一种方法会产生什么）。

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

Answer 1

这是很难回答，因为有两个明显的好处 - 一个票TPH和其他为TPT：

• 您模型非常适合TPH因为所有属性都是在基类和派生类不会为表添加属性。因此，三个实体的所有查询（或两个，如果Cases是抽象的）只需要这个表，并且不涉及任何连接 - >对性能有好处。另一方面，该数据库将允许您的模型不一致，例如具有Emails记录，CaseId = 1指的是Cases记录，此Id = 1但Type鉴别符是TwitterCase。如果你只使用EF来访问数据库，如果EF正确地执行它的工作，这个调整不应该发生。如果您有其他来源可能会更改数据库，可能会发生。

• TPT会解决的可能模式不一致的问题，因为CaseId在Emails表将参照随后的EmailCases表和CaseId在Tweets表到TwitterCases表。但价格是你有这些奇怪的表，它只包含主键的一个列，每个查询 - 不管它有多简单 - 都会涉及Cases表与派生类型的表之间的联接 - >对于性能。

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