关闭

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

标签: DBA与项目的那堆事Hibernate项目ORM
1150人阅读 评论(0) 收藏 举报
分类:
     曾经有人让我对一个数据库的优化给点建议. 一个典型的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
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:528217次
    • 积分:7701
    • 等级:
    • 排名:第2745名
    • 原创:247篇
    • 转载:1篇
    • 译文:0篇
    • 评论:271条
    链接分享
    最新评论