Question

我正在使用Entity Framework Database的第一种方法来创建我的域模型。

我正在考虑使用以下基础属性创建一个基表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

我相信这对于Entity Framework会很好用，但我担心从数据库的角度来看这是不错的设计。

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

思想？

Answer 1

OO概念很少转化为关系数据库。作为一名DBA，我花了更多的时间来清理将OO概念变成关系数据库的尝试而不是其他任何事情（并不是因为我是一个纯粹主义者，而是因为他们没有工作。）

如果你想在所有实体中使用独特的PK，请查看guids（或连续guid）

这些列（CreatedDate，ModifiedDate等）在每个实体表中都不会受到任何伤害（事实上，这是正确的设计）但是，当你再次加入到基表时，你会看到糟糕的查询计划然后再次。

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

Answer 2

最大的问题是性能。你所描述的是TPT继承，直到带有next version of EF的.NET 4.5，这将是very inefficient queries的场景。

如果是ObjectContext API，它还有一个额外的缺点。您不能拥有ObjectSet派生类型，因此您将以所有实体的单个对象集结束。

如果你想要好的OOP概念定义与你的字段的接口并在你的所有实体中实现它，但不要使用跨越概念和存储模型的继承来绑定你的实体。甚至TPC也不是很好的解决方案，因为它仍然需要所有表中的唯一主键=＆gt;它导致了guids。

Answer 3

我能看到的明显好处是我得到了一个独特的PK 整个数据库中的实体。

您是否可以通过使用HiLo算法或类似的身份来实现这一目标？

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

3 个答案: