现在我们在hibernate中还需要使用多表查询吗？

JDBC有非常多的不好，代码死、不便于维护、与数据库类型耦合等等，但它有它的优势使我们至今都不能抛弃它。它执行效率高，而且最贴近数据库，使得它可以100％完成数据查询的各种变态需求，特别是复杂查询的需求。而hibernate我们可以说出它满篇的好处，但它的致命伤是不能满足所有查询的需求。举一个我做过项目的例子。我做过一个项目，是一个分析决策系统。它的最核心部分，也是它其存在价值的部分，就是对另一个联机事务系统中的上千个日常数据的分析处理。由于业务逻辑复杂，这部分的查询语句非常复杂，常常一个语句有上百行，包含数层子查询和多个union，其间的各种函数就不用说有多少了。如果这样的语句用hibernate来完成，几乎是不可能实现，即使实现了也是效率极低的。采用jdbc应当是正确的选择。hibernate能解决70％的查询需求，但不是全部。

你说的hibernate的效率问题我也遇到过。在hibernate2的时候由于延迟查询不成熟，几乎不敢做任何一对多的关联。比如在一个内部评审项目中，一个评审计划对应多个评审者，一个评审者对应多个评审表，一个评审表对应多个疑点问题。一旦程序要装载一个评审计划，它包含的所有评审者、评审表、疑点问题，出一堆东西，简直是数据库的灾难。但是hibernate3出来以后，通过延迟查询解决了这个问题。虽然使用延迟查询似乎感觉sql语句多了不少，但评判查询效率的标准决不是语句的多少，而是语句产生结果集的多少以及执行查询其过程的效率。

但是，hibernate依然存在着执行效率的问题，这不可否认。使用hibernate始终没有单独使用jdbc的效率高，但hibernate还是有它解决执行效率的办法，那就是缓存。缓存对于hibernate解决效率问题其实作用很大。比如员工显示列表中需要显示每个员工的部门名称，也就需要为每个员工装载他所在的部门。也就是说，查出多少个员工就要执行多少次对部门的查询（部门表是一个一个查询的），但其实很多次查询都是查出的同一条部门数据。如果采用缓存，当某个部门被查出来以后就暂存在应用服务器内存中，如果需要再次装载这个部门就不需要查询数据库了，直接从应用服务器中取，对效率的提高是相当大。在使用hibernate查询时这种情况相当普遍，因此将那些基础数据表和代码表纳入缓冲是相当有用，因为它们总是1+N查询中的N。但是那些业务表，一方面是更新频繁，另一方面它们总扮演1+N查询中的1，不对它缓存也罢。不知我说的这些是否对你有帮助。

Java对象没必要一直存在于内存中

你的意思是hibernate没有必要做缓存吗？如果是这样我倒是有一些不同的看法。现在我们是3层结构，就意味着应用服务器与数据库服务器是2个不同的机器。当客户发出请求时，如果仅仅在应用服务器上进行运算以后向客户反馈，当然比从应用服务器到数据库服务器，再返回结果集到应用服务器，再反馈客户的效率高。因此，我们在编写java代码的时候，应当考虑尽量少的访问数据库。hibernate通过uuid获得主键就是一个很好的例子。从这个角度理解，hibernate采用应用服务器端的数据缓存对于提高效率就显得比较重要了，它可以大大降低应用服务器对数据库的访问。

需要分页的时候， 这一对多关联如何做？？