EF遗传和DNA关注

Question

对于一个新项目，我们的应用程序开发人员希望使用Entity Framework的每类型表继承模型。

我们最近向我们的DBA展示了这个功能和结果表模式，他表达了担忧，我想知道如何解决这些问题。继承是OO的重要组成部分，从开发方面来说，让DB和ORM本身支持这个概念会很棒。此功能是EF的一部分，因此我们不会将设计从左侧场中拉出来。

他的主要担忧是：

• 我们没有使用存储过程
• 增加的复杂性将使报告和数据更新更难

我们已经解决了他存储的proc问题（我们已经使用了另外一个ORM 3年了。）

就复杂性而言，我确实看到了他的观点，但对立点解决了这些问题（对我而言）：

• 不应该从事务表（我们目前这样做）执行报告，应该使用视图或转换的报告数据库。
• 更平坦的结构上的数据更新仍然会弄乱数据 - 更新数据的人员有责任理解结构。 EF的每个类型的表继承模型使用的模式并不复杂，但在进行手动更新时必须遵守该模式。

我知道我们不是第一个因数据库支持的模型继承而遇到DBA问题的人。其他人如何说服他们的DBA这是一个好模型？

Answer 1

他主要担心的是没有考虑TPT的实际问题。

• 如果需要，可以将存储过程与TPT一起使用。
• 数据更新并不困难。 EF将处理它们并确保正确的数据修改顺序。

TPT的主要问题是inefficient queries（也请查看评论）。 EF中的TPT具有真正的性能问题，因为即使它不需要派生表中的数据，它也会产生很多左连接和联合。创建任何关于此数据结构的报告并通过EF访问报告数据是非常糟糕的决定。

编辑：

如果他的问题与使用您的数据库的其他工具有关，那么它们是完全合法的，但同时它只是关于数据库结构的正确文档。