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