hql与延迟加载

Question

hibernate

Answer 1

我暂时的一个解决方法是和 hibernate调用getXXX()方法时的延迟加载实现方式一样，即在hql中直接写多表连接查询，把所需得全部一次性得到。

Answer 2

你这相当不靠谱，你这样全部写hql是可以，但hibernate getXXX()方法绝对不能用，否则用一次查询一次

Answer 3

你这相当不靠谱，你这样全部写hql是可以，但hibernate getXXX()方法绝对不能用，否则用一次查询一次
这个很靠谱，除非几乎所有情况都需要加载的关联对象，都要设置为lazy。需要加载自己join啊

Answer 4

你这相当不靠谱，你这样全部写hql是可以，但hibernate getXXX()方法绝对不能用，否则用一次查询一次
这个很靠谱，除非几乎所有情况都需要加载的关联对象，都要设置为lazy。需要加载自己join啊确实呀，全部延迟加载的话，大部分查询都需要自己写hql join 查询了，这样子运行效率确实靠谱，但编写效率却降低很多，这已经是最优方案了么，不能再折中折中？

Answer 5

如果你大部分都自己写hql join查询的话，说明你的业务很经常需要大量的关联数据，一般的情况下，比较少情况下会把大量数据的延迟加载对象都要拿出来的，拿个别几个，用getXXX()让他去查库要比hql join来的便捷。

Answer 6

你这相当不靠谱，你这样全部写hql是可以，但hibernate getXXX()方法绝对不能用，否则用一次查询一次
这个很靠谱，除非几乎所有情况都需要加载的关联对象，都要设置为lazy。需要加载自己join啊确实呀，全部延迟加载的话，大部分查询都需要自己写hql join 查询了，这样子运行效率确实靠谱，但编写效率却降低很多，这已经是最优方案了么，不能再折中折中？
懒惰的使用hibernate已经把有些操作变得效率比较低了，比如你只想更新表的一个字段（比如状态），有些人却直接使用session.update,或者entityManager.merge方法，这样效率降低了不少，如果表数据量比较大就会显现的比较明显了。另外比如opensessioninview方式，如果只是几十个人用的小oa还可以考虑，但是用户多的系统，或者网站，这种方式就是不可接受的。使用join编写效率是低了一点，在我看低了一点点而已，但是能确保系统最健康的运行。我从来就是用join的方式。还有更精确一点的方式，比如列表要显示对象某几个属性，并且显示一个关联对象的1个属性，这时应该直接使用select子句，仅查询需要的字段，不需要的就不要查。必须精确控制你的查询，不仅是运行效率的问题，而且还有内存使用的问题。

Answer 7

如果你大部分都自己写hql join查询的话，说明你的业务很经常需要大量的关联数据，一般的情况下，比较少情况下会把大量数据的延迟加载对象都要拿出来的，拿个别几个，用getXXX()让他去查库要比hql join来的便捷。饿，说的太笼统了，你的意思也是全部设置成延迟加载吧，然后在大量查询时用join查询，其他就不用管是吧

Answer 8

用HQL join fetch 就能直接查出  主要看你怎么用  如果查找主对象之后  不直接用从对象  而是对主对象做一系列操作后再用  那么延迟加载就合理  如果查出来马上就用  那就一次性全查出来

Answer 9

lz应该考虑hibernate框架自身的考虑，在2.x的时候，默认全是非延迟的，3.x默认改为延迟的了。可想而知，在2.x使用的时候出过多少问题，以致于曾经有人说hibernate只能做点小应用玩玩，其实他是不知道关联可以设置为延迟加载的。所以hibernate框架在3.x中把这个默认值修改为延迟了，这也符合真正系统开发的实际。

Answer 10

看来，只有全部设置成延迟加载才能把效率提到最高，需要的时候再去根据单个查询或多个查询选择是否join查询去得到数据，不用加载延迟基本无法避免冗余数据的多取，因为很少存在这样两个表：索取a表数据的任何时候也都会同时需要b表的数据。

Answer 11

你这相当不靠谱，你这样全部写hql是可以，但hibernate getXXX()方法绝对不能用，否则用一次查询一次
这个很靠谱，除非几乎所有情况都需要加载的关联对象，都要设置为lazy。需要加载自己join啊确实呀，全部延迟加载的话，大部分查询都需要自己写hql join 查询了，这样子运行效率确实靠谱，但编写效率却降低很多，这已经是最优方案了么，不能再折中折中？
懒惰的使用hibernate已经把有些操作变得效率比较低了，比如你只想更新表的一个字段（比如状态），有些人却直接使用session.update,或者entityManager.merge方法，这样效率降低了不少，如果表数据量比较大就会显现的比较明显了。另外比如opensessioninview方式，如果只是几十个人用的小oa还可以考虑，但是用户多的系统，或者网站，这种方式就是不可接受的。使用join编写效率是低了一点，在我看低了一点点而已，但是能确保系统最健康的运行。我从来就是用join的方式。还有更精确一点的方式，比如列表要显示对象某几个属性，并且显示一个关联对象的1个属性，这时应该直接使用select子句，仅查询需要的字段，不需要的就不要查。必须精确控制你的查询，不仅是运行效率的问题，而且还有内存使用的问题。赞，确实是这样