映射继承实体中的导航属性(TPH)

Question

我有以下数据库架构：

​

我正在使用Table-per-Hiearchy (TPH)继承。案例表的"Type“字段确定案例是电子邮件案例还是twitter案例。它们与Cases表都是1:N关系。

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

​

​

问题是我不能使用外键(Email.CaseId <-> Cases.Id和Tweets.CaseId <-> Cases.Id)将导航属性映射到子表中。我希望实现的是，EmailCase实体有一个指向电子邮件的导航属性，而TwitterCase实体有一个指向推文的导航属性。

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

我该如何解决这个问题？我应该使用Table-per-Type (TPT)而不是TPH吗？但在这种情况下，例如，EmailCase将只包含原始情况的ID，其他情况对我来说听起来都很奇怪。(这是如果我使用模型优先方法将生成的内容。)

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

Answer 1

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

您所建模的

• 非常适合于TPH，因为所有属性都在基类中，并且派生类不会向表中添加任何属性。因此，这三个实体(如果Cases是抽象的，则为两个)的所有查询只需要这个表，并且不涉及->连接，这有助于提高性能。另一方面，数据库会允许模型的不一致，比如让一个CaseId=1的Emails记录引用这个Id=1的Cases记录，但是Type鉴别器是一个TwitterCase。如果您只使用EF访问数据库，如果EF正确地执行其工作，这种缝合应该永远不会发生。
• TPT可以解决可能出现的模型不一致的问题，因为Emails表中的CaseId会引用EmailCases表，而Tweets表中的CaseId会引用TwitterCases表。但代价是，您有这些奇怪的表，它们只包含主键的单个列，并且每个查询-无论多么简单-都将涉及Cases表和派生类型的表之间的连接，这对performance.

不好

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