面向对象分析问题，开发系统是程序员的福音，这点我很有同感，但是一直没有对ORM框架进行深入的研究。最近公司开发一个项目，由于技术总监是搞数据库的，所以一直在以数据库建表方式构架系统，大家知道，搞数据库表不可避免的要设计很多细节，功能细节，实现细节。目前项目进展非常缓慢。我在项目组一直倡导首先业务建模，但是没有引起足够重视，其中一个原因是技术总监怀疑ORM的性能问题，他说：“屏蔽了数据库，那怎么优化数据库，不优化数据库，怎么保证系统的性能？”不知道ORM对性能影响如何？数据库仅仅作为持久化的地方，没有数据库优化支持又会如何？我最近也在研究开源搜索引擎lucene，这可以直接精确检索数据，有了这个，也会降低对数据库性能优化要求。使用过lucene的道友也可以谈一下感想。
请彭老师和广大道友指点一二，拜谢！
[该贴被leonshine于2008-04-14 14:58修改过]
[该贴被leonshine于2008-04-14 14:59修改过]
[该贴被leonshine于2008-04-14 15:00修改过]
ORM在SQL优化方面，当然比纯SQL语言要差。但是ORM框架的性能可以靠缓存提高。以Hibernate来说，二级缓存和查询缓存可以极大缓解数据库的查询压力。灵活使用缓存，可以让系统的性能有极大提升。
从页面、到应用层、持久化，缓存只要设计得合理，甚至比纯SQL还要快。毕竟对象缓存在本机内存里，无论如何也比从数据库中拿快。
还有，你说的数据库优化到底是怎么优化？
猫说得很对。楼主的这些总监恐怕要与时俱进，及时进行知识更新，我已经在jdon写了大篇文章倡导大家抛弃数据库思维。
>屏蔽了数据库，那怎么优化数据库，不优化数据库，怎么保证系统的性能？
屏蔽了数据库，那么数据库优化就基本不起作用，也就不需要了，问这个问题的人思维中有一个潜意识，软件系统都必须依靠数据库优化的，这其实是误区。
正如猫所说的，但我们将业务都变成一个业务对象，并且运行在内存中时，缓存和内存是对业务系统最好的优化，当然，优化数据库也会起到作用，不过这种作用的用处就不是很大，属于微调，不能上升为架构设计高度了。
在php上我用的较多，曾经有一会大牛是这么讲的：
现在的php已经够了，慢在访问数据库，所以不管你怎么优化都很难从一个层次上提升访问速度.
道理相同:
数据库的优化只是一个方面.不能全面的解决问题.很多的应用从是从缓存上去减小数据库的访问压力.
要是再抱着数据库不放的话,我看得饿死了... XD
前段时间我看到一篇大概是PHP创始人炮轰Java在Web上已经输了，看了标题，我就不用看内容，知道这是回光返照式的呼喊。
1998年我搞Perl，当时书籍都没有，搞PHP，也没有书籍，当然再搞Java，同样找不到Web方面的书籍。我对PHP超过Perl的易用性是肯定的，但是我一直强调，没有一个尺寸的裤子适合所有人，没有一种解决方案适合所有情况，易用的背面必然有所牺牲。
PHP存在大量过程化编程和混杂Html这些在Java世界中早就摒弃的做法（虽然近期也在改善），更重要的是：PHP系统的设计和性能都依赖数据库。
我已经在“对象和数据库阻抗”一文中说明数据库和OO的矛盾，如果你承认OO好处，那么就必要要落实OO，摒弃关系数据库分析和设计的做法，而PHP系统如果失去数据库，它就是一个空壳，所以看出，PHP+关系数据库已经处于上个世纪的架构。
对象和数据库阻抗
http://www.jdon.com/mda/oo-reltaion2.html
从性能上讲，分布式缓存能够提供强大的分布式处理，或者可以用云计算等这些新式的分布式计算方式来比喻，而依靠关系数据库，只能走集中式主机等60年代老路子。
当然，如果PHP能够摆脱对关系数据库依赖，象Java那样作为一个独立品格的语言能够从弯腰到站起来，那也一样会继续辉煌，可怕的是不思进取。
关于过程化编程方法的坏处，很多初学者可能没有体会，下面这个例子就是使用过程化没有任何设计的案例，结果程序出问题，作者自己都找不出来，打个比喻，你家里很乱，你自己都无法在家里找到丢失的东西，别人更不可能，只能叫几个人一起找，打人力规模站，编程也是这样，过程化编程一复杂就等于你家里乱了。
所以，作为一个程序员自己编出的程序自己都无法找到问题，无法修改，这个程序就是垃圾，过程化编程就是很容易造成这种垃圾程序，白学习，白干活。
http://www.jdon.com/jivejdon/thread/33877.html
[该贴被banq于2008-04-18 09:34修改过]
YY也要有一个限度么，楼上几位都夸大了ORM所谓缓存的作用，在一个高性能要求的系统里，依靠Hibernate这样的纯ORM作为DAC的核心只会拖累整体性能急剧下降。
如果是通过主键等这样键值来建立缓存尚可，此类问题在实际运用中却并不多见。
大多数应用都是通过复合查询条件甚至表间关联来搜索数据。
Hibernate就是100级缓存也无法解决SQL复合查询的缓存命中，道理很简单：
ORM的缓存不是万能的查询引擎，对于复合查询和多表联合的复杂情况，缓存是无能为力的，否则他就是一个Database而不是一个Cache了。因此，对于一些常见的简单查询来说，缓存能极大提升你系统的反应，但是更多的是你需要针对客户的查询请求做出反应，这可不是一个缓存所能解决的。
ORM要解决的问题是结构模式问题，而数据库是要解决存储与查询问题，两者的目标和方向并不一致，因此在性能上，毫无疑问的是Database的长项；而以Hibernate为代表的ORM是把Database的数据模型转换为对象模型来访问，从而提高程序的可维护性、可扩展性，而不是提高程序的性能。
所以，如果你的项目只是搞搞OA或者一些并发性能要求不高的系统，ORM足够应付局面；反之，如果你的系统是一个高性能要求的、大并发量的系统，那么在时间关键的代码里Hibernate是无能为力的，目前的ORM技术来说都无能为力，表模式仍然是高速度的代表。
[该贴被minehe于2008-04-25 14:53修改过]
[该贴被minehe于2008-04-25 14:54修改过]
楼上观点有只是从ORM和表结构单纯比较，没有看到对象性质介入其中，这个对象是业务对象，是根据当前业务系统建立的常用几个对象，比如销售系统，销售单是一个业务对象，一般企业系统最经常操作的是集中一段时间，比如当前一个月，所以，在这个月中的销售单将被缓存，这种缓存实际就是根据每个不同系统优化后的缓存，而表模式缓存则不可能有这种针对这个应用业务系统的优化。
多表查询改为多个对象在内存中进行组合，关系数据库的多表查询更有弱点，否则google就会用关系数据库多表查询来做搜索引擎，使用关系数据库做全文搜索简直是恶梦，而google创造的基于缓存的云计算说明了关系数据库实际是纸老虎一个，很简单当前这个论坛就是使用lucene而不是关系数据库实现搜索，而PHP架构的DisCuz!则使用关系数据库搜索，简直不能用。
我举例说明：关系数据库的多表查询是大而不当，具体业务应用又可以被缓存+对象组合替代，它的生存价值越来越小。
放什么P!"一般企业系统最经常操作的是集中一段时间，比如当前一个月，所以，在这个月中的销售单将被缓存"
争着眼睛说瞎话.
缓存只是提高性能的一种手段
最厉害的缓存也需要数据的支持
而且,如果是一般企业,那就不需要做缓存.因为数据操作不频繁,也基本不需要考虑性能.要考虑性能的话,也只需要考虑计算机的硬件设备就够.
如果涉及到数据,光靠缓存没用.
不合理的设计,足以把服务器拖跨.
草,YY什么.