我有一个每日批处理过程，包括选择大量记录并格式化文件以发送到外部系统。我还需要将这些记录标记为已发送，以便明天不再发送。
以我天真的JDBC方式，我会准备并执行一个语句，然后开始遍历记录集。因为我只是通过记录集前进，所以我的应用程序服务器不需要一次将整个结果集保存在内存中。可以从数据库服务器提供记录组。
现在，假设我正在使用hibernate。我不会立刻用一堆表示内存中整个结果集的对象来结束吗？
答案 0 :(得分：5)
Hibernate也会迭代结果集，因此只有一行保留在内存中。这是默认值。如果它贪婪地加载，你必须这样说。
使用Hibernate的原因：
原因不使用Hibernate：
答案 1 :(得分：3)
Hibernate提供了一些保持会话小的可能性。
您可以使用Query.scroll（），Criteria.scroll（）进行类似JDBC的滚动。您可以使用Session.evict（对象实体）从会话中删除实体。您可以使用StatelessSession来抑制脏检查。还有一些性能优化，请参阅Hibernate文档。
答案 2 :(得分：2)
Hibernate，因为任何ORM框架都旨在基于面向对象的编程主体来开发和维护系统。但是大多数数据库都是关系型的，而不是面向对象的，因此无论如何ORM总是在方便的OOP编程和优化/最有效的数据库访问之间进行权衡。
我不会将ORM用于特定的隔离任务，而是作为应用程序持久层的整体架构选择。
答案 3 :(得分：1)
在我看来，我会不使用Hibernate，因为它会使你的应用程序变得更大，更难以维护，并且你真的没有机会快速优化生成的sql脚本。 此外，您可以使用JDBC-Bridge支持的所有SQL功能，而不仅限于hibernate功能。另一件事是你也有各种遗留代码层的限制。
但最终这是一个哲学问题，你应该按照最适合自己的方式来做。
答案 4 :(得分：0)
如果可能存在性能问题，请坚持使用JDBC代码。
有许多众所周知的纯SQL优化 这在Hibernate中很难做到。
仅选择您使用的列！ （没有“选择*”的东西）。
保持SQl尽可能简单。例如不要在联接中包含小型参考表，如货币代码。而是将货币表加载到内存中，并通过程序查找解析货币描述。
取决于SQL的次要重新排序，其中谓词可能对性能产生重大影响。
如果您要更新/插入每100到1000次更新只提交一次。即不要承诺每一个单位的工作，而是保留一些反击，这样你就不会经常犯下这些工作。
利用数据库的聚合函数。如果你想要DEPT代码的总数，那么在SQL中使用“SUM（金额）...... GROUP BY DEPT”进行总计。