(04) 调优碰上Hibernate,真心无力

     曾经有人让我对一个数据库的优化给点建议. 一个典型的J2EE项目,标配的SSH框架，好像一切都很美好。可 面对这个Hibernate,个人感觉DBA真心无力啊.  

      它把数据库的东东映射成类,使用HSQL,然后可以自动生成SQL。 或许对Java或C#开发人员来说,Hibernate或Nhibernate是个不可多得的东东，认为 它可以利用缓存来提高系统运行效率.还可以跨数据库.总之好处多多，所以用得很广。

     我没认真研究过这类ORM,但很有疑问.

     1. 映射成类，利用缓存来提高系统运行效率

       虽然我没验证过，但在数据库中直接用函数或存储过程效率难道不更高?

     2. 跨数据库?

       真正项目中,数据库换来换去或要支持多数据库的相对还是比较少.

       我更多的是发现为了框架而框架的多些. 为了这个可能用不上的特性而把数据库大部份特性给报废掉?何必呢．

　 3.很重要的一点．HSQL自动生成的SQL,让DBA功力全废的 感觉，学了SQL调优十八法，硬是没地方使劲．

　憋得难受啊． 只能从表设计，索引等这些方面入手，但这些通常都要开发配合，哪是那么好弄的?

　　　

      对于已弄好的库咱没办法，那从库设计着手有没办法呢.　我去百度百科查了下Hibernate

数据库设计的原则:

数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制并不完全一样
d) 适当的冗余数据，不过分追求高范式

     按这种数据库设计思想，表和表关联需要以简单为主，以便于分成很多一个个的小类。开发时，业务逻辑稍微复杂或与数据库交互较多， 前面开发的会写得累，数据库性能也不高，所以再次回到第一个问题，在数据库中直接用函数或存储过程效率难道不更高?

　 或者说随着系统上线模块越多，业务越复杂，这种方式看起来都会很累．

而且这种方式，以后真碰到性能瓶颈. 将只能从开发端着手．数据库端基本无能为力．但开发端的优化真正碰到大数据量时．呵呵。呵呵。

     不要认为大数据量不常见，实际上现在的数据量很容易就上去了。大数据时代已经到来。

　

     不过不管怎么说它，SSH已成为标配，成功的项目有很多很多．但在我角度上，这是一种强开发，弱数据库的方式．它有它的价值，但至少我不太喜欢它．　

MAIL:xcl_168@aliyun.com
Blog:http://blog.csdn.net/xcl168