1. 庫表的複雜度，首先取決於需求，不取決於設計，設計能力強的人，也要遵守庫表設計的規範，從巴克斯三個範式上，原則上也要遵守。不能說用了 Hibernate,自己的庫表設計能力就強了。不能爲了用Hibernate，就去一味批判複雜的關係不對。複雜的關係設計對不對，首先取決於是否有復 雜的需求，其次才取決於設計者的能力。
2. 只要你用的是關係數據庫，就必須要明白，爲什麼叫關係數據庫，而不叫面向對象數據庫，把面向對象的那些觀點，拿到庫表設計上，後期維護和調優上，你要擔起 責任，不能讓開發人員替早期決策人員擦屁股。我見過有的人，打着OO和擴展性的旗號，硬生生的把一個表，拆成了三個表，而這三個表，本來，只需要增加一個 類型字段，再做一些冗餘，就可以是一個表。現在查詢時，還要把這三個表Union到一塊來查。當需求變更時，增加一個字段，不僅要改變三個類，還要改變三 個表，簡直是亂倫。
3.One-One的庫表設計，對於DBA來講，並不是一個best practice的設計。不能爲了Hibernate，刻意把大表拆成小表，再用幾個小類，做成One-One的映射關係。整體性，是不能隨便的分割，畢 竟開發人在調試、測試和維護的時候，更喜歡看數據庫裏的數據，本來一個SQL，就查出來，現在要到多個表中去查。
4. 增刪改存的實體維護
Ibatis比不上Hibernate，說實在話，現在讓我寫SQL來維護一個多對多關係的實體維護，我都要考慮上半天，別說寫代碼了。
5. 你需要寫原生SQL嗎
首先你要確認，你項目的要求不需要寫原生SQL，再來講Ibatis和Hibernate的好壞，在寫原生SQL上，特別是動態生成的
SQL，ibatis比Hiberante有得一拼，ibatis就像一個模板一樣，將SQL寫在配置文件當中，集中配置，特別方便技術領導者監控項目成
員寫的SQL好壞，而且沒有什麼學習曲線，就寫SQL就完事了。
有人會說，Hibernate也支持寫SQL，但是寫代碼當中，就失去了原來基於Hibernate的DAO的簡潔性。那個DAO一點也不簡潔，如果你將 動態拼SQL的代碼也放在DAO當中，那個DAO就會充斥大量的If 。。Else。。之類的語句，一坨一坨的，非常的壯觀。
還有人會說，Hibernate也支持命名查詢，將SQL寫在映射文件當中，但是命名查詢，只支持佔位符固定的情況，也就是說，where a = ? and b = ? and c=?，是三個問號，就是三個問號，傳參時，少一個都不行。但是很多項目的查詢，都是動態的，也就是說用戶選了這個查詢條件，纔會生成這個佔位符的。
Hibernate辦不到。
還有人會說，我自己用Hibernate寫一個框架，也可以做到，那你寫的可能比Ibatis好，也可能差，你要造輪子，誰來攔不着。
5. 調優
早期調優，有些Bad SQL，其實在code
review階段，只要看看Ibatis的SQL配置文件，就可以扼殺掉的，如果使用HSQL，可能不會被發現，因爲它不僅隱藏在代碼當中，有的時候，還
需要程序跑起來，通過日誌打印出SQL或者通過其它工具如P6Spy來看的出來。
後期調優，既然是調優，我想就一定是遇到了瓶頸，可能要在庫表上做冗餘，可能要檢查那些Bad SQL，可能要修改代碼，可能要動用DBA層次上的一些調優手段，那麼調優越深入，Ibatis的優勢就越能體現出來，比如說增加臨時表，中間表，增加冗 餘字段等。
6. 開發速度
如果項目當中，沒有一個Hibernate高手，你的項目又相對的複雜，不僅有複雜的庫表關係，還有大量的報表查詢，那麼使用Hibernate，速度上遜於Ibatis.
問題在於，怎麼樣算是一個Hibernate高手，別看論壇上，那麼多人，羣情激奮的在說Hibernate的好，有誰真的是高手？
我認識一個人，連Hibernate的命名查詢、悲觀鎖、樂觀鎖之類的，都不清楚，還在那說：“說Hibernate不好的人，只是他不會用 Hibernate，高手使用EJB也一樣用的很順溜“，我這輩子，最最討厭的就的這樣的人，人家明明用Spring很簡單，很快樂，爲什麼要用EJB， 充高手。換過來，項目使用Ibatis來做動態查詢，很快的就解決問題了，爲什麼要去學Hibernate裏面高深的東東，是不是這樣就是高手了？
7. 平臺移植性
如果你的項目要做產品，而且打算基於多個數據庫平臺的發佈，使用Hiberante是沒有說了。
8. 維護性
如果不考慮移植性，Ibatis的可維護不差於Hibernate，庫表變動引起實體類變動時，HSQL也會有改動，有人說不用改，說這話的那個人可能整天只會有select * ，如果ibatis也是這樣寫，也不用動了。
HSQL好閱讀嗎，From order，確實很簡單，但實際當中，這跟拿HelloWord做例子，有什麼區別？
9. 我在實際項目當中的運用
項目背景：
我自己從Hibernate2開始使用，我現在也不認爲我是Hibernate高手，我也沒有時間去鑽研Hibernate，更深的東西，我也不喜歡坐在開發人員旁邊老半天，去幫他們解決Hibernate遇到的問題，因爲我自己還有很多事要做。
我的項目當中，在Hibernate方面，還有一個比我更強的人，他也很煩去看Hibernate打印出來的sql，看上老半天，再調上老半天，項目進度，嗖嗖的過去了。
水平越高的人，任務越重，很少有時間和耐心去解決一般性的問題。
最終的運用：
在基於Spring的容器事務管理之下，
增、刪、改、存及在事務中的查詢，使用Hibernate。
非事務性的查詢及報表，都用Ibatis，維護非常的直觀方便，開發速度上也快很多。
我覺得現在技術換代很快，使用一項技術，首先是要快速的解決問題，然後要學習他的思想，那些整天死抱着Hibernate，自認爲學習到ORM的設計技巧的人，就去繼續的學吧。
我已經會用Hibernate的一些方面，我覺得夠用就行了，犯不上，天天鑽研HSQL，如果有時間，我覺得躺在草坪上看看Unix的編程藝術，看看代碼大全，看看Oracle的編程藝術，比看Hibernate的SB書要愜意多了。
簡單能夠帶來快樂，用過EJB，再用Spring的人，都有體會，那簡直是一種思想上的重生。
Ibatis的設計者認爲，在新的項目當中，可以使用Hibernate，在舊的遺留項目當中，可以使用Ibatis，不明白，他爲什麼說這樣的話，這與新舊項目有什麼區別？ 新的項目就真的可以使用Hibernate嗎。