近日，在JavaEye论坛中，看了Ibatis和Hibernate的帖子，看后，心里觉得的憋闷，不说不快, 这里 ，我想更细化一下：
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的优势就越能体现 出来，比如说增加临时表，中间表，增加冗余字段等。