问题描述
|
对于一个新项目，我们的应用程序开发人员希望使用Entity Framework的逐类型表继承模型。
我们最近向DBA展示了此功能和生成的表模式，他对此表示了担忧，我想知道如何解决这些问题。继承是OO的重要组成部分，从开发的角度来看，让DB和ORM本地支持此概念将是一件很棒的事情。此功能是EF的一部分，因此，这与我们将设计从左域中拉出来并不一样。
他主要关心的是：
我们没有使用存储过程
增加的复杂性将使报告和数据更新更加困难
我们几乎已经解决了他存储的proc问题（并且我们已经使用另一个ORM已有3年了）。
就复杂性而言，我确实看到了他的观点，但对点针对它们（对我而言）解决了这些问题：
不应从事务表中执行报告（我们目前正在这样做），应使用视图或转换后的报告数据库。
在较平坦的结构上进行数据更新仍然会弄乱数据-更新数据的人员有责任了解结构。 EF \的每类型表格继承模型使用的架构并不复杂，但是在进行手动更新时必须遵循该架构。
我知道我们并不是第一个因数据库支持的模型继承而遇到DBA的人。其他人如何说服他们的DBA这是一个好的模型？
解决方法
他主要关心的问题不是考虑TPT的实际问题。
如果需要，可以将存储过程与TPT一起使用。
数据更新并不难。 EF将处理它们并确保正确的数据修改顺序。
TPT的主要问题是查询效率低下（也请检查注释）。 EF中的TPT确实存在性能问题，因为即使它不需要派生表中的数据，它也会进行很多左联接和联合。在此数据结构上创建任何报告并通过EF访问报告数据确实是一个错误的决定。
编辑：
如果他的担忧与使用数据库的其他工具有关，那么它们是完全合法的，但与此同时，这仅与数据库结构的正确文档有关。