我对hibernate和mybatis框架的比較

Posted 2020-09-18 slgkaifa

    系统在选择操作数据库的框架上面，究竟是选择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生成的工具。事实上就是把数据库当做一个黑盒。好像不须要对它有深入的了解，这样是被误导，看看我们如今有些组开发的报表开发工具，假设遇到大数据量，往往歇菜。