ORM 提供的查询语言 (QL) 的表达能力非常强大。不幸的是，一旦您有一组复杂的查询，然后出现一些令人费解的模式或数据问题，就很难获得您需要的 DBA 帮助？在这里，他们是开发数据库的团队的一部分，但他们无法读取应用程序 QL，更不用说提出修改建议了。我通常最终会为他们从日志中获取生成的 SQL。但是，当他们建议对其进行更改时，这与原始 QL 有何关系？该过程不是往返的。
因此，在宣传 ORM 的价值十年之后，我现在想知道是否应该手动编写 SQL。也许我真正希望框架做的只是尽可能地自动化数据编组。
问题：您是否找到了处理组织中往返问题的方法？是否有一个可扩展且易于维护的 SQL 编组框架？
（是的，我知道纯 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 概念更接近它们。