大家来一起讨论如何通过Hibernate提高访问数据库的速度

最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3
由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢，由于项目时间比较短，时间很紧，所以一直都在忙着实现功能，还没来的急进行优化
今天我设置下二级缓存效果不大，我想肯定还有更好的方法，比如Hibernate.initialize 还有迫切连接等方法
请大家多给点意见，最好给一个详细的技术文章
谢谢大家~！

首先必须明白：性能问题完全取决于你的业务设计问题，而不是某个具体架构技术的性能。

你的业务设计采取面向数据表分析，导致关系复杂表和表之间的关系很多，这是你的系统性能问题最本质原因，只有使用DDD重新分析你的系统，才从根本上改观。

其他只是一些小修小打的微调，不能根本解决问题。

捆绑上hibernate，你就走上了死亡的战车。

彭老师，正好要问你一下，原来的JDon的Message的示例是采用Hibernate2实现的，现在用Hibernate3如何实现？调试发现很多地方有问题~

如果不能掌握Domain Model的设计方式，使用ORM是比较艰难的。不如No ORM，看看TSS前段时间讨论的：No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715

非常有意思，当初Hibernate刚出来时，有人和我争辩：NO EJB,NO EntityBean，大肆指责EJB实体Bean使用复杂，推崇Hibernate，如今还是同样的轮子，说明主要问题是我们建模方式不对，我会专门文章讨论

英文论坛啊，看起来有些费力，哈哈……不过明白您的意思了，我们会考虑实际情况的，相信是有办法的。

>>首先必须明白：性能问题完全取决于你的业务设计问题，而不是某个具>>体架构技术的性能。
感觉banq越来越偏激了，似乎“水变油”的理论在这里也能得到正解了。

很同意,有些人主动或被动把SQL搞得很复杂,这本身就背离了OR MAPPING的初衷,也背离了持久曾的实质.
好的DB设计不会有复杂的SQl代码,基本就是简单的CRUD语句,在它上层再用一层Service实现复杂的业务机制.当然,这必须在领域对象已经清晰的情况下.

另外在用户闲置时间做一些数据处理工作也是很好的,等用户登录后直接就呈现给他,不用被动的等待命令再行动.

up!

我也觉得banq有点偏激了！！

每种技术都有优缺点，最根本的还是programmer的素质，知道如何运用technologies, 而不是选取那种framework or technology.

我倒是觉得这次banq说的在理。
当然不能说完全取决于业务设计(或者数据库设计)，但这个可以说是比较主要的原因。

那应该怎么呢？
请给个例子可以让我学习一下可以么
我的邮箱sunxianchao333@hotmail.com
再请教个问题什么时候用hibernate呢为什么我在这里的公司没有用呢
是电信这样的大公司啊

>再请教个问题什么时候用hibernate呢为什么我在这里的公司没有用呢
>是电信这样的大公司啊

使用Hibernate前提必须掌握领域建模的方法，也就是Evans DDD，至少了解类关联的意思和本质。

我们以前很多程序员都是基于数据表编程的思路，现在使用了Hibernate这样的ORM，Hibernate替代了数据表，或者说；插在了数据表和程序员之间，程序员就看不见数据表了，程序员必须学会和Hibernate代表的对象打交道，如果还是念念不忘数据表，那么每次用Hibernate，总是要转个弯，就不自然而且不方便。

换句话说：只有程序员真正掌握面向对象的分析设计和编程，才会觉得使用Hiberante等ORM工具是一个最简单的方式，否则，反而觉得数据表JDBC是一个简单的解决方式。

所以，可以从是否善用Hibernate看出程序员的OO素质。虽然你的单位是电信大单位，但是OO作为一个与面向过程全新的革命性技术和思想，它是挑战和颠覆面向过程的思维的，而我们国内以前大学教育以及实践如Delphi/VB等等都是传统的面向过程思维，虽然他们做过大项目，经验丰富，但是也吃了很多苦头，只是朴素地直觉认为程序要灵活，但是没有上升为OO理论，因为掌握OO是对自己过去经验和习惯的挑战，是对自己的挑战，又有几个人做到，象你这样舒服的大单位，谁有没事折磨自己，挑战自己呢？