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

最近我和一朋友讨论如何在在spring+hibernate框架下设计通用的查询程序。设计通用的查询程序，对于单表查询比较容易，只要把要查询的值对象和查询条件作为条件传递给后台就可以执行查询了。而从结果集中取值也比较容易，因为结果集就是这个值对象的集合。但要是设计一个通用的多表查询程序就比较复杂了，涉及多个值对象、值对象的关联、查询条件的前缀、取值等等问题。我提出一个观点，现在的hibernate可以不需要多表查询，运用单表查询以及值对象的各种关系就可以完全实现所有多表查询的功能。

为什么这么说呢？比如我们需要获得一个部门及其下面的所有员工。过去我们需要将部门和员工这2个表进行关联进行多表查询，但现在我们只需要在设计部门值对象的时候为其增加一个一对多关联，然后通过单表查询部门表，在每个部门值对象的员工属性中就有其所有的员工了。再比如，如果我们需要在查询员工的时候显示各个员工所在部门的部门名称，现在我们也同样不需要多表查询了。只需要在员工值对象中建立员工到部门的多对一关系，在单表查询员工的时候，每个员工值对象中都有部门属性，对应的是部门值对象，包含了其所在部门的全部信息。

以上提供了运用单表查询以及值对象的各种关系替代多表查询最常见的2种情况，而hibernate还提供了一对一、多对多、3种继承关系，我认为可以含盖几乎所有需要使用多表查询的应用。所以我认为，hibernate发展到现在，我们可以几乎不需要使用多表查询。编写一个通用的单表查询程序就可以应付大多数使用hibernate的查询程序，除了复杂查询。hibernate不适用于复杂查询，不论是易用性、效率来看都不适合。

我有个疑问, 比如部门和该部门下的员工,设置了一对多的关系,但有的业务我不需要查询出该部门下的员工 而 有的业务需要查询出员工, 如果该部门有很多员工 在不需要查询员工的时候 也把员工加载出来 会不会 很浪费资源呢? 怎么样能解决这个问题?

尽管hibernate提供了一对一、多对多、3种继承关系，但是习惯的更改的确很困难，拼SQL有些时候的确很方便，很灵活。

出报表的时候你怎么办
N表查询

misschun朋友似乎还不知道hibernate的延迟查询。hibernate在查询员工表的时候并不会马上加载部门信息，解决了不需要查询员工时的效率问题，而在你真正需要使用部门信息的时候才去加载，这被称为延迟查询。在hibernate2的时候，由于可能出现session关闭的问题，延迟查询并不成熟。hibernate3推出了OpenSessionInView，解决了该问题，因此hibernate3默认就是使用延迟查询。

出报表的时候，如果报表是简单查询，依然可以如我所说的进行单表查询。如果是复杂查询，就不要使用hibernate而改为jdbc也许更方便快捷。
问题是什么是简单查询。我在这里指的简单查询是那些仅仅是表间关联和数个条件组成的，不包含任何函数、求union以及多层子查询等复杂操作。
如我以上说的简单查询，即使出现数个表关联，并且从各个不同表中设置条件，hibernate的单表查询都是可以应付的。比如员工与部门形成多对一、与项目形成多对多、与住址形成一对一，同时员工与工作计划、工作计划与绩效考核、绩效考核与考核工资等多表形成链状关联，都可以通过员工进行单表查询。并且，我们可以通过“员工.工作计划.绩效考核.考核工资.考核工资ID=某个值”就可以对该员工表的查询进行条件限定。如果你采用了这种单表查询，我的示例也许可以提供给你一个通用查询的方案供你参考。http://fangang.iteye.com/blog/120768，你可以看看BasicDao中的query方法。
但是，如果报表的查询是以上提到的复杂查询的情况就不太方便使用单表查询了，不如直接使用jdbc。但这种情况在项目中往往只会在报表统计中出现，在整个项目中占的比重小。以上的讨论可以解决大部分查询的问题。

延迟加载 不是在 配置文件里 写的吗?  不就写死了吗? 我hibernate不是很好 ,不好意思.

我选择创建视图

我是这样想的：

1、在写数据、更新/删除数据中Hibernate很实用，很方便。

2、在分析展示数据时还是拼写SQL来的方便。

看来你是应当好好看看书。写死是指在java程序中写死了，今后如果需要修改设置就需要修改程序，不利于维护，称为写死。在配置文件中设置延迟加载了，如果今后不需要延迟加载，仅仅只需要修改配置文件而不需要修改任何java程序，这就不是程序写死了。