使用表继承是否有效避免使用连接表？

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派生类。但是，这两个类之间的唯一区别是存在Case字段或Task字段。当然，在数据库中，我将有一个表，Artifact，带有类型鉴别器字段以及CaseId和TaskId字段。

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

Answer 1

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

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

如果您只是将设计良好的对象模型保存到数据库中，那么在不通过镜头的情况下查看数据库时，您的数据库将没有太多内在价值（难以将数据挖掘，报告，仓库，元数据模糊等）对象模型 - 这对某些应用程序来说很好，通常不适用于我的。

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

Answer 2

我会考虑在案例和任务之间找到共性，因为缺少更好的单词，我们称之为“ CaseTask ”然后再 - 从那个开始（继承）。之后，您将文档附加到超类型。

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