ORM提供的查询语言（QL）的表现力非常强大。不幸的是，一旦你有一系列复杂的查询，然后出现一些令人费解的架构或数据问题，很难获得你需要的DBA帮助？在这里，他们是正在发展数据库的团队的一部分，但他们无法阅读应用程序QL，更不用说建议修改了。我通常最终会从日志中获取生成的SQL。但是当他们建议对其进行更改时，它与原始QL有何关系？这个过程不是往返的。
因此，经过十年推广ORM的价值，我现在想知道我是否应该手动编写我的SQL。也许我真正希望框架做的就是尽可能地自动化数据编组。
题：您是否找到了解决组织中往返问题的方法？是否有一个SQL-marshaling框架可以很好地扩展，并且可以轻松维护？
（是的，我知道纯SQL可能会将我绑定到数据库供应商。但它 是 可以编写符合标准的SQL。）
我认为您想要的是一种解决方案，可以最大限度地利用ORM的好处，而不会阻止您使用其他方法。我们在申请中遇到了同样的问题;非常繁重的查询和大型数据模型。鉴于数据模型的大小，ORM对于绝大多数应用程序来说都是非常宝贵的。它允许我们扩展数据模型，而无需花费大量精力手工维护SQL脚本。而且，你谈到了这一点，我们支持四个数据库供应商，所以抽象很好。
但是，有些情况下我们必须手动调整查询，因为我们选择了灵活的ORM解决方案，我们也可以这样做。正如你所说，当我们需要它时，它会让我们失去方向，而只是为我们编组对象。
所以，简而言之（是的，简称）是的，ORM是值得的，但就像问题的每个解决方案一样，它不是灵丹妙药。
一般来说，ORM会大大提高开发人员的工作效率，因此我会使用它们，除非它们成为一个比它们值得更大的问题。如果您的大多数表都足够大以至于您遇到很多问题，请考虑放弃ORM。我绝对不会说ORM通常是一个坏主意。大多数数据库都足够小，大多数查询都很简单，它们运行良好。
我通过使用存储过程或手写SQL仅针对性能较差的查询来克服这个问题。 DBA喜欢存储过程，因为他们可以在不告诉您的情况下修改它们大多数（如果不是全部）ORM允许您混合手写SQL或存储过程。
今天的O / R框架，我相信你熟悉，支持手动定义一些查询的选项（（N）Hibernate）。可以用于模式的复杂部分，对于直接部分，可以使用框架提供的ORM。
你要检查的另一件事可能是iBatis框架（http://ibatis.apache.org/）。我没有使用它，但我已经读到它更接近于SQL，熟悉数据库和SQL的人更喜欢它，而不是像hibernate这样的全面的ORM框架，因为它比完全不同的ORM概念更接近它们。