谈谈目前自己对hibernate的了解
Hibernate主要是使用OO思想存取数据库，根据数据库表自动映射对象，代码全部转为针对对象的操作，语义表达相比原来
的rs要强很多。Hibernate的关键是有针对数据库表的设计和编程转变为针对业务对象的设计和编程。
但是Hibernate有一个缺陷，可能是由于要把数据库表映射为对象，使用Hibernate可能会出现严重的性能问题，速度很慢等情况。
参考资料：
大家来一起讨论如何通过Hibernate提高访问数据库的速度
http://www.jdon.com/jive/thread.jsp?forum=16&thread=28484
最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3
由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢，由于项目时间比较短，时间很紧，所以一直都在忙着实现功能，还没来的急进行优化
今天我设置下二级缓存效果不大，我想肯定还有更好的方法，比如Hibernate.initialize还有迫切连接等方法
请大家多给点意见，最好给一个详细的技术文章
谢谢大家~！
re：
首先必须明白：性能问题完全取决于你的业务设计问题，而不是某个具体架构技术的性能。
你的业务设计采取面向数据表分析，导致关系复杂表和表之间的关系很多，这是你的系统性能问题最本质原因，只有使用DDD重新分析你的系统，才从根本上改观。
其他只是一些小修小打的微调，不能根本解决问题。
如果不能掌握DomainModel的设计方式，使用ORM是比较艰难的。
re：
很同意,有些人主动或被动把SQL搞得很复杂,这本身就背离了ORMAPPING的初衷,也背离了持久曾的实质.
好的DB设计不会有复杂的SQl代码,基本就是简单的CRUD语句,在它上层再用一层Service实现复杂的业务机制.当然,这必须在领域对象已经清晰的情况下.
re：
使用Hibernate前提必须掌握领域建模的方法，也就是EvansDDD，至少了解类关联的意思和本质。
我们以前很多程序员都是基于数据表编程的思路，现在使用了Hibernate这样的ORM，Hibernate替代了数据表，或者说；插在了数据表和程序员之间，程序员就看不见数据表了，程序员必须学会和Hibernate代表的对象打交道，如果还是念念不忘数据表，那么每次用Hibernate，总是要转个弯，就不自然而且不方便。
换句话说：只有程序员真正掌握面向对象的分析设计和编程，才会觉得使用Hiberante等ORM工具是一个最简单的方式，否则，反而觉得数据表JDBC是一个简单的解决方式。
所以，可以从是否善用Hibernate看出程序员的OO素质。虽然你的单位是电信大单位，但是OO作为一个与面向过程全新的革命性技术和思想，它是挑战和颠覆面向过程的思维的，而我们国内以前大学教育以及实践如Delphi/VB等等都是传统的面向过程思维，虽然他们做过大项目，经验丰富，但是也吃了很多苦头，只是朴素地直觉认为程序要灵活，但是没有上升为OO理论，因为掌握OO是对自己过去经验和习惯的挑战，是对自己的挑战，又有几个人做到，象你这样舒服的大单位，谁有没事折磨自己，挑战自己呢？
re：
呵呵,我也是做电信项目的,看了一下,发表一下自己的观点,电信项目的数据量大,表的数目也比较多,业务逻辑也比较复杂,如果用oo设计,对象之间的关联比较多,而且比较复杂,所以load一条数据非常慢,另外,需求变更比较频繁,往往在项目过程进行中需要进行表的改动,面向对象有可能需要重新设计对象之间的关系,维护起来不方便,而且在数据查询优化方面也利用不到数据库的优势,导致查询数度比较慢,个人观点是对象分析可以帮助我们深入了解对象与对象之间的关系,也就是表与表之间的关联,但实际开发中可能就需要将对象关系降低,而且用户只关心他需要的数据,就是视图,我不否认oo的优势,但实际开发另当别论,不要因为oo而oo,另外提一下,上次公司有个项目用hib,差点死掉.......(说的不对别骂哦,呵呵^_^)
re：
这个世界上的软件并不永远只有CRUD这种操作，统计/分析/报表等等同样是必不可少的，如果捆绑上hibernate，就如j10a所说，绝对会在性能上走向死亡。
通常我会在项目中同时使用hibernate和jdbc，当然，会有自己的封装。
单纯做ORM，我倒是觉得itabis是个更好的选择。
re：
我很认同banq。之前，有3、4个项目使用hibernate。问题很多，一是项目组没有非常熟悉hibernate组员，二是我们对业务领域根本没有分析，基本上是沿袭老思路，建库，创表，编代码。需求在不断变更，问题越来越多。
现在，这个项目，我们在业务领域分析方面，做了一点小工作，并且借鉴spring的思路，多在行为定义，行为组装上下功夫，尽量解耦行为与数据、行为与数据关系。应该说，比原先有所进步。我相信，随着项目组对hibernate的深入，对OO的深入，对业务领域分析的深入，我们的路会越来越清晰。
re：
我也很认同banq的观念，因为从数据表建模的思路转变到对象建模思路，我也有过这样的经历，以前设计系统时都是从数据库建模开始，这样的问题是如果你采用对象的方式编码的话，很多问题都出来了，结果项目的代码也被改动的的很多，而且维护也很麻烦。现在我如果从头设计一个系统，我往往先是业务对象建模，业务对象先运行起来，在用代理模式或装饰模式给业务对象增加防问数据库的能力。这样代码改动量虽然没见得减少，但改动的范围缩小了，控制在几个类之间，而且便于维护。
re：
不得不承认，web2.0时代已经来临，这个强调性能、敏捷的时代，hibernate会死的更早。呼唤一个崭新的框架!OO很重要，但过于强调就是“女人的裹脚布”了，又臭又长！
re：
其实，没有必要争论是JDBC，HIBERNATE哪个效率高，哪个好，同样的问题不同人的解决结果也未必一样，有些人用JDBC写的SQL访问数据库未必比HIBERNATE快，所以人是关键・
几个月前，一次经历：由于设计问题，使客户一次操作产生几千条SQL，这样明显是设计问题，后来采用工具+DEBUG，拦截宋庆龄，看看是什么地方产生的问题，最后找出问题，把几千条变为几条，性能提高越30倍。
最夸张的是有个同事发了HIBERNATE产出的SQL让我查错，竟然是几页WORD的SQL，我没有能力找错误，这问题在什么地方，在设计！
所以用HIBERNATE，你是不是准备好了，公司的技术储备是不是可以，是不是已经从数据分析转道对象，领域分析了，是否清楚如何设计合理的对象关系，所以HIBERNATE只是O/R工具，他需要分析设计先行的基础！
re：
彭先生，说的非常用理，只有你采用面向对象思想分析系统，重构系统，才能使Hibernate体现的淋漓尽致，如果你的系统还是采用数据库方式驱动设计，而不采用DDD设计，再怎么优化还是有问题，原因何在，原因出在现在大部分系统有人还是没能走出数据库驱动方式开发系统阴影，还是用面向对象的语言而不是思想开发系统，从而使系统本质上不是面向对象的．因此还是建议重构吧．
re：
我对hb不是很了解,正在学习中,简单说一下自己的想法:
系统开发过程中,问题来自多方面，比如说用了hb,查询性能下降很多，
可能会是多中原因造成的，比如，开发人员熟悉hb的程度够不够，能不能对HQL语句进行优化；对hb的长处和短处是否理解，知道什么情况下，使用hb的缓存会提高性能；
另外，还有设计的问题，对象的粒度是否合适，类和表怎样映射才更合理...
总之一句话，你对hb理解到什么程度，写出的程序的性能也会不同！
re：
你把lazy设成true就可以,当lazy为false的时候,数据抓取会抓出一棵树,所以会很慢.把lazy设成true以后你可以根据自己具体需要来抓数据,具体可参考hibernate手册的fetch语句.