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的緩存優點，就必須把表設計的儘可能細顆粒度，消除冗餘和多重依賴，最終多是至關多的小表，表之間經過主外鍵關聯，可是關聯關係都是單一的。那麼這種追求面向對象的數據庫模型是很是符合三大範式的。