系统在选择操作数据库的框架上面，到底是选择hibernate,还是mybatis。 首先说下两者的原理，如果你要关联几张表做查询,查出20条记录: 1.如果是mybatis SELECT * FROM (SELECT INNER_TABLE.*, ROWNUM OUTER_TABLE_ROWNUM FROM (select SP_WORK_PLAN.name, spr
系统在选择操作数据库的框架上面，到底是选择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
WHERE OUTER_TABLE_ROWNUM > 0;
2.如果是hibernate,像下面的SQL要查20次。
织梦DEDE5凭借其专业的技术、丰富的电子商务经验在第一时刻为此最流行的购物方式推出开源程序。独立编译模板、自由修改、代码简洁，安全高效、数据缓存等技术的应用，使其能在大浏览量的环境下快速稳定运行，切实节约网站成本，提升形象。同行业比较，织梦DEDE5的优势在哪里？整体规划 摒弃开发速度慢，效率低下、冗余严重的框架。投入大量的时间和精力，打造最简洁高效的程序开源程序 我们渴望公平、公正、开放的竞争
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，实现很简单，hold住。
3.运维阶段的影响
在运维阶段每天监控数据库，找到性能隐患，是业界的最佳实践。如果是hibernate的架构，即使我们找出了问题SQL，也无法对改动SQL进行调优，因为它是生成处理的，最多加一个索引。
最后：全部用hibernate对DB操作，把hibernate当做一个SQL生成的工具，其实就是把数据库当做一个黑盒，好像不需要对它有深入的了解，这样是被误导，看看我们现在有些组开发的报表开发工具，如果遇到大数据量，往往歇菜。
