hibernate与数据库建模--原做robbin

其实围绕Hibernate的话题，我都已经说过不下30遍，以至于最近两年以来，我对全部Hibernate的问题都不肯意再回应。另外最近一年多来，使用Rails的ActiveRecord，让我对ORM的认识又加深了不少，其实对于那么多争议的问题，最好的解决办法就是本身去实践。对于本身没有去实践过的东西，争是争不出来什么的。 

引用

一、以数据库为中心建模 VS 以领域模型为中心建模： 
老开发人员大多倾向于前者，由于比较符合过去的开发习惯，另外他们强调数据库的生命周期大于App 
向我这样的只有几年工做经验的每每会倾向于后者，由于这能更充分发挥ORM的威力，更符合OO，免去不少维护DB的繁琐工做。

数据库设计三大范式如雷贯耳，但做为非科班出身的我直到两个月前居然都不知道三大范式到底是什么。那么三大范式是什么？ 

引用

第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。 

第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的状况），也即全部非关键字段都彻底依赖于任意一组候选关键字。 

第三范式（3NF）：在第二范式的基础上，数据表中若是不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是若是存在"A → B → C"的决定关系，则C传递函数依赖于A。

两个月前当我购买了一本《MySQL权威指南》，翻到三大范式的定义的时候，我心里巨震，三大范式简单总结一句就是消除冗余，单纯依赖关系。不容许数据库表出现冗余字段，不容许表之间多重依赖，所以符合三大范式设计的数据库模型其实和你按照面向对象思想去建模获得的数据库模型是同样的。 

因此不论你是从数据库为中心建模，仍是你以领域模型为中心建模，你应该最终获得一个一致的数据库模型。之因此致使数据库建模和OO建模的不一致，是所以传统的数据库建模历来都是违背三大范式的。而咱们在过去常常说的一句话就是：为了数据库查询性能，咱们须要多加一些冗余字段，不必定非要遵循三大范式...... 

因此不要再说什么数据库设计和面向对象设计致使的数据模型冲突的话，不是他们冲突，是你违背了三大范式，本身制造出来的冲突。 

引用

二、Hibernate VS iBatis/JDBC： 
担忧失去对SQL待控制权，致使不能作优化，DBA反对 
Hibernate是在JDBC之上的又一层框架，所以想固然的认为其性能不如iBatis/JDBC（我认为这个结论不成立，由于引入一个ORM层给了咱们更多机会去优化性能，好比一二级缓存、lazyload、查询缓存，而且方式更优雅）。参考为何ORM性能比iBATIS好？ 
担忧OpenSessionInView模式有性能问题（http://www.iteye.com/topic/17501） 
Hibernate没法应付复杂查询（我认为这不是问题，HQL和criteria查询能力很强，再不济还能够用SQL啊）

JavaEye网站的数据库设计是面向对象为中心的设计，可是拿三大范式来衡量，大部分设计都是吻合的，而咱们的数据库缓存命中率在90%左右。缓存服务器的流量是数据库服务器流量的2.5倍之多。事实上咱们有不少地方的查询尽可能避免join，宁肯让他n+1，这样速度反而更快，缓存命中率更高。 

例如咱们如今把帖子的内容字段拆分出来，单独放在一个post_texts表里面。这样posts表实际上只有35MB，而post_texts表有1GB。每次显示一个post，都会用主键去load post_text，命中缓冲。不须要查数据库，不须要去碰那个1GB的大表。 

要充分发挥ORM的缓存优点，就必须把表设计的尽可能细颗粒度，消除冗余和多重依赖，最终多是至关多的小表，表之间经过主外键关联，可是关联关系都是单一的。那么这种追求面向对象的数据库模型是很是符合三大范式的。