所有实体都继承自一个主基表的优缺点是什么？

Question

我使用实体框架数据库的第一种方法来创建我的域模型。

我正在考虑使用以下基本属性创建一个基表 EntityBase：

 PK
 CreatedDate
 CreatedBy
 ModifiedDate
 ModifiedBy

 etc.

使用 Table Per Type 继承，我最终会在数据库中得到一个链接到所有其他实体表的表：

EntityBase {
 EntityBase_PK => Identity PK
 CreatedDate
 CreatedBy
 ModifiedDate
 ModifiedBy
}

DerivedEntity1 {
 DerivedEntity1_PK => FK relationship to EntityBase on EntityBase_PK
 Property1 
 ...etc
}

DerivedEntity2 {
 DerivedEntity2_PK => FK relationship to EntityBase on EntityBase_PK
 Property2 
 ...etc
}

...etc

我相信这将适用于实体框架，但我担心从数据库的角度来看这是否是好的设计。

我可以看到的明显好处是，我为整个数据库中的所有实体获得了一个唯一的 PK，但我担心每次更新都会影响 EntityBase 表，这可能是一个性能问题，并且会对表锁定产生影响。

想法？

Answer 1

OO 概念很少转化为关系数据库。作为一名 DBA，我花了更多的时间来清理将 OO 概念硬塞到关系数据库中的尝试（不是因为我是一个纯粹主义者，而是因为它们不起作用。）

如果您想要跨所有实体的唯一 PK，请查看 guids（或连续 guids）

将这些列（CreatedDate、ModifiedDate 等）放在每个实体表中不会有任何伤害（实际上，这是正确的设计）但是，当您一次又一次地连接回基表时，您会看到糟糕的查询计划。

简而言之，我建议不要这样做。

Answer 2

最大的问题将是性能。您所描述的称为 TPT 继承，直到 .NET 4.5 与下一个版本的 EF出来，这将是查询效率非常低的场景。

在ObjectContextAPI 的情况下，它有一个额外的缺点。您不能拥有ObjectSet派生类型，因此您将以为所有实体设置的单个对象结束。

如果您想要良好的 OOP 概念，请定义与您的字段的接口并在您的所有实体中实现该接口，但不要将您的实体与跨越概念和存储模型的继承绑定在一起。即使 TPC 也不是很好的解决方案，因为它仍然需要所有表中唯一的主键 => 它会导致 guids。