.net - 在继承实体 (TPH) 中映射导航属性

Question

我有以下数据库模式:

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

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

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

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

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

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

Answer 1

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

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

• TPT 将解决可能的模型不一致问题，因为 Emails 表中的 CaseId 将引用 EmailCases 表，并且Tweets 表中的 CaseId 到 TwitterCases 表。但代价是你有这些奇怪的表，它们只包含一个主键列，每个查询 - 无论它多么简单 - 都将涉及 Cases 表和表之间的连接派生类型 -> 不利于性能。

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