O/R Mapping值得吗？

ORM提供的查询语言(QL)的表现力非常强大.不幸的是,一旦你有一系列复杂的查询,然后出现一些令人费解的架构或数据问题,很难获得你需要的DBA帮助？在这里,他们是正在发展数据库的团队的一部分,但他们无法读取应用程序QL,更不用说建议修改了.我通常最终会从日志中获取生成的SQL.但是当他们建议对其进行更改时,这与原始QL有何关系？这个过程不是往返的.

因此,经过十年推广ORM的价值,我现在想知道我是否应该手动编写我的SQL.也许我真正希望框架做的就是尽可能地自动化数据编组.

问题:您是否找到了处理组织中往返问题的方法？是否有一个SQL-marshaling框架可以很好地扩展,并且可以轻松维护？

(是的,我知道,纯SQL可能约束我的数据库供应商,但它是可以编写符合标准的SQL.)

我认为您想要的是一种解决方案,可以最大限度地利用ORM的好处,而不会阻止您使用其他方法.我们在申请中遇到了同样的问题; 非常繁重的查询和大型数据模型.鉴于数据模型的大小,ORM对于绝大多数应用程序来说都是非常宝贵的.它允许我们扩展数据模型,而无需花费大量精力手工维护SQL脚本.而且,你谈到了这一点,我们支持四个数据库供应商,所以抽象很好.

但是,有些情况下我们必须手动调整查询,因为我们选择了灵活的ORM解决方案,我们也可以这样做.正如你所说,当我们需要它时,它会让我们失去理智,而只是为我们编组物品.

所以,简而言之(是的,简称)是的,ORM是值得的,但就像问题的每个解决方案一样,它不是灵丹妙药.

一般来说,ORM会大大提高开发人员的工作效率,所以除非他们成为一个比他们更值得的问题,否则我会使用它们.如果您的大多数表格足够大以至于您遇到很多问题,请考虑放弃ORM.我绝对不会说ORM通常是个坏主意.大多数数据库都足够小,大多数查询都很简单,以至于它们运行良好.

我通过仅对性能较差的查询使用存储过程或手写SQL来克服这个问题.DBA喜欢存储过程,因为他们可以在不告诉您的情况下修改它们 大多数(如果不是全部)ORM允许您混合手写SQL或存储过程.