系統在選擇操作數據庫的框架上面，究竟是選擇hibernate,還是mybatis。

首先說下兩者的原理，假設你要關聯幾張表做查詢,查出20條記錄:

1.假設是mybatis
SELECT *
FROM (SELECT INNER_TABLE.*, ROWNUM OUTER_TABLE_ROWNUM
FROM (select SP_WORK_PLAN.name, sprocorgan1_.code --僅僅是查詢
from SP_WORK_PLAN workplanvo0_,
v_sp_organization sprocorgan1_,
V_SP_USER sprocuserv2_,
v_sp_organization sprocorgan3_,
V_SP_USER sprocuserv4_,
V_SP_USER sprocuserv5_,
v_sp_organization sprocorgan6_
from workplanvo0_.APPLY_DEPARTMENT_OID =
sprocorgan1_.ORG_ID and
workplanvo0_.CONFIRMATION_UID = sprocuserv2_.USER_ID and
sprocuserv2_.ORG_ID = sprocorgan3_.ID and
workplanvo0_.CREATE_UID = sprocuserv4_.USER_ID and
workplanvo0_.WORK_MASTER_UID = sprocuserv5_.USER_ID and
workplanvo0_.WORK_TEAM_ID = sprocorgan6_.ORG_ID) INNER_TABLE
WHERE ROWNUM <= 20) OUTER_TABLE
WHERE OUTER_TABLE_ROWNUM > 0;

2.假設是hibernate,像以下的SQL要查20次。

select
workplanvo0_.ID as ID9_6_,
workplanvo0_.UPDATE_TIME as UPDATE2_9_6_,
workplanvo0_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_9_6_,
workplanvo0_.CODE as CODE9_6_,
workplanvo0_.DATA_FROM as DATA5_9_6_,
workplanvo0_.DATA_STATE as DATA6_9_6_,
workplanvo0_.END_LIFECYCLE as END7_9_6_,
workplanvo0_.NAME as NAME9_6_,
workplanvo0_.START_LIFECYCLE as START9_9_6_,
workplanvo0_.FLOW_STATE as FLOW10_9_6_,
workplanvo0_.PROCESS_INS_ID as PROCESS11_9_6_,
workplanvo0_.ACTUAL_END_TIME as ACTUAL12_9_6_,
workplanvo0_.ACTUAL_START_TIME as ACTUAL13_9_6_,
workplanvo0_.APPLY_DEPARTMENT_OID as APPLY40_9_6_,
workplanvo0_.ATTENTION_LEVEL as ATTENTION14_9_6_,
workplanvo0_.COMPLETE_CONDITION as COMPLETE15_9_6_,
workplanvo0_.CONFIRMATION_TIME as CONFIRM16_9_6_,
workplanvo0_.CONFIRMATION_UID as CONFIRM41_9_6_,
workplanvo0_.CREATE_UID as CREATE42_9_6_,
sprocorgan1_.ID as ID26_0_,
sprocorgan1_.UPDATE_TIME as UPDATE2_26_0_,
sprocorgan1_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_26_0_,
sprocorgan1_.CODE as CODE26_0_,
sprocorgan1_.DATA_FROM as DATA5_26_0_,
sprocorgan1_.DATA_STATE as DATA6_26_0_,
sprocorgan1_.END_LIFECYCLE as END7_26_0_,
sprocorgan1_.NAME as NAME26_0_,
sprocorgan1_.START_LIFECYCLE as START9_26_0_,
sprocorgan1_.AREA_ID as AREA10_26_0_,
sprocorgan1_.STATE as STATE26_0_,
sprocuserv2_.ID as ID27_1_,
sprocuserv2_.UPDATE_TIME as UPDATE2_27_1_,
sprocuserv2_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_27_1_,
sprocuserv2_.CODE as CODE27_1_,
sprocuserv2_.DATA_FROM as DATA5_27_1_,
sprocuserv2_.DATA_STATE as DATA6_27_1_,
sprocuserv2_.END_LIFECYCLE as END7_27_1_,
sprocuserv2_.NAME as NAME27_1_,
sprocuserv2_.START_LIFECYCLE as START9_27_1_,
sprocuserv2_.ACCOUNT as ACCOUNT27_1_,
sprocorgan3_.ID as ID26_2_,
sprocorgan3_.UPDATE_TIME as UPDATE2_26_2_,
sprocorgan3_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_26_2_,
sprocorgan3_.CODE as CODE26_2_,
sprocorgan3_.DATA_FROM as DATA5_26_2_,
sprocorgan3_.DATA_STATE as DATA6_26_2_,
sprocuserv4_.ID as ID27_3_,
sprocuserv4_.UPDATE_TIME as UPDATE2_27_3_,
sprocuserv4_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_27_3_,
sprocuserv4_.CODE as CODE27_3_,
sprocuserv4_.DATA_FROM as DATA5_27_3_,
sprocuserv4_.DATA_STATE as DATA6_27_3_,
sprocuserv4_.END_LIFECYCLE as END7_27_3_,
sprocuserv4_.NAME as NAME27_3_,
sprocuserv5_.ID as ID27_4_,
sprocuserv5_.UPDATE_TIME as UPDATE2_27_4_,
sprocuserv5_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_27_4_,
sprocuserv5_.CODE as CODE27_4_,
sprocuserv5_.DATA_FROM as DATA5_27_4_,
sprocuserv5_.DATA_STATE as DATA6_27_4_,
sprocuserv5_.END_LIFECYCLE as END7_27_4_,
sprocorgan6_.ID as ID26_5_,
sprocorgan6_.UPDATE_TIME as UPDATE2_26_5_,
sprocorgan6_.OPTIMISTIC_LOCK_VERSION as OPTIMISTIC3_26_5_,
sprocorgan6_.CODE as CODE26_5_,
sprocorgan6_.DATA_FROM as DATA5_26_5_,
sprocorgan6_.DATA_STATE as DATA6_26_5_,
sprocorgan6_.END_LIFECYCLE as END7_26_5_,
sprocorgan6_.NAME as NAME26_5_,
sprocorgan6_.START_LIFECYCLE as START9_26_5_,
sprocorgan6_.STATE as STATE26_5_
from
SP_WORK_PLAN workplanvo0_
left outer join
v_sp_organization sprocorgan1_ on workplanvo0_.APPLY_DEPARTMENT_OID=sprocorgan1_.ORG_ID
left outer join
V_SP_USER sprocuserv2_ on workplanvo0_.CONFIRMATION_UID=sprocuserv2_.USER_ID
left outer join
v_sp_organization sprocorgan3_ on sprocuserv2_.ORG_ID=sprocorgan3_.ID
left outer join
V_SP_USER sprocuserv4_ on workplanvo0_.CREATE_UID=sprocuserv4_.USER_ID
left outer join
V_SP_USER sprocuserv5_ on workplanvo0_.WORK_MASTER_UID=sprocuserv5_.USER_ID
left outer join
v_sp_organization sprocorgan6_ on workplanvo0_.WORK_TEAM_ID=sprocorgan6_.ORG_ID
where workplanvo0_.ID=? ;

1.設計階段的影響
無法驗證模型的合理性和預測性能。依據界面原型做數據庫設計，長處是能夠保證數據都能存到數據中，不足之處是無法保證模型的合理和性能。

假設調整架構用ibatis，我們能夠在設計完畢後，寫代碼之前把復雜的查詢寫出來，制造一些數據進行性能預測。

2.開發階段的影響
a.Hibernate無法使用層次查詢、分析函數、正則表達式等。不錯。hibernate有調用SQL的結果。假設通過接口調用SQL,不便於調試，用ibatis很適合調試。
b.在開發階段也無法預測性能,就是測試SQL。

c.hibernate的內部實現比較復雜。假設沒有人能讀懂裏面的源碼。最好是僅僅使用最簡單的增、刪、改。查（依據主鍵查）。反觀mybatis，實現非常easy。hold住。

3.運維階段的影響

假設是hibernate的架構，即使我們找出了問題SQL，也無法對修改SQL進行調優。由於它是生成處理的。最多加一個索引。
最後：所實用hibernate對DB操作。把hibernate當做一個SQL生成的工具。事實上就是把數據庫當做一個黑盒。好像不須要對它有深入的了解，這樣是被誤導，看看我們如今有些組開發的報表開發工具，假設遇到大數據量，往往歇菜。

我對hibernate和mybatis框架的比較