使用表继承是避免使用连接表的有效方法吗？

Question

我一直在为这个项目遵循主要是 DDD 方法，因此，像任何 DDD 一样，我首先创建了我的域模型类。我的意图是将这些 POCO 用作我的 LINQ-to-SQL 实体（是的，它们不是纯 POCO，但我可以接受）。我已经开始创建数据库架构和外部映射 XML 文件，但是在建模实体的关系和关联时遇到了一些问题。

一个工件代​​表一个文档。工件可以与任务或案例相关联。 Case 实体如下所示：

public class Case 
{
     private EntitySet<Artifact> _Artifacts;
     public IList<Artifact> Artifacts
     {
          get
          {
               return _Artifacts;
          }
          set
          {
               _Artifacts.Assign(value);
          }
     }
     .
     .
     .
}

由于 Artifact 可以与 Case 或 Task 关联，因此我可以选择使用 Artifact 类的继承来创建 CaseArtifact 和 TaskArtifact 派生类。然而，这两个类之间的唯一区别是是否存在案例字段或任务字段。当然，在数据库中，我将有一个表 Artifact，其中包含类型鉴别器字段以及 CaseId 和 TaskId 字段。

我的问题：这是解决此问题的有效方法，还是为每个关联（总共 2 个新表）创建一个连接表是更好的方法？

Answer 1

我可能会使用两个表 - 它使引用完整性 - PK/FK 在数据库中的处理更简单一些，因为您不必有基于选择器列的复杂约束。

（回复您的评论 - 我的空间用完了，所以在这里发布作为编辑）我的总体理念是数据库应该使用数据库最佳实践建模（保护您的边界并确保数据库一致性，使用尽可能多的 RI 和约束，通过 SP 提供所有访问，根据需要记录活动，控制所有访问模式，在必要时使用触发器）并且对象模型应该使用 OOP 最佳实践建模，以提供强大且一致的 API。处理阻抗失配是您的 SP/数据访问层的工作。

如果您只是将设计良好的对象模型持久化到数据库中，那么在不通过对象模型 - 这对于某些应用程序来说很好，通常不适用于我的应用程序。

如果您只是在应用程序中模仿设计良好的数据库结构，而不提供丰富的 OO API，那么您的应用程序将难以维护，并且内部结构将难以处理 - 通常非常程序化、僵化且具有很多代码重复。

Answer 2

我会考虑在 case 和 task 之间找到共同点，因为没有更好的词，我们称之为“CaseTask”，然后再分-从那个打字（继承）。之后，您将文档附加到超类型。

更新（评论后）：
然后我会考虑这样的事情。每个文档都可以附加到多个案例或任务中。