不选或许有千万种理由，但是选择hibernate只需要一个理由就足够了

打sql这招数我们也玩。
沟通出问题的例子：
DBA说看这个sql没多少可优化的，你们搞这个sql是干嘛的，看看能不能换个思路写或者改库表结构来改进。
程序员拿出来，DBA对着类图和hsql中间一堆.就晕掉了。
这种情况，DBA学点hibernate基础会很有帮助。
不用管缓存啊验证啊什么的，知道关联啥意思，能和开发团队交流起来。
可话说回来，要真有hibernate达人，我相信和DBA合作也不会有问题。

看业务方面吧。

比如大量采用新技术的公司，规模不太大的话，需要程序员会的多，未必要精通。

像大型项目的dba，他们要学习的东西也很多很杂，而且其思路已经有所局限，不是不学，而是难有作为。

分工不同罢了。

强求人人会hibernate没什么必要，既然采用hibernate，那么负责j2ee这块的负责人就得有这种觉悟：hibernate不是做不到，而是要学的深入。指望把j2ee该搞定的事情推到dba头上去学习是不负责任的做法

1.数据库设计的时候，DBA应该要适当参与评估的。

2.如果某些模块对性能有要求，某些数据抓取的策略是要有人牵头，评估的，这个人可以是开发人员，也可以是架构师，只要有人牵头，一些复杂的数据抓取策略在实现前就先简单沟通一下，就不用等后期出了性能问题再解决。

3.一般来说，数据库设计的时候，是要考虑到数据存入、抓取、更新的策略，这一阶段设计完善的话，后续都是有办法的，这一阶段的设计其实和是否用hibernate没有太大的必然联系，hql最终也是要变成sql的，除非是某些针对性的数据库的特殊sql，一般的通用sql优化策略（例如数据抓取的策略），无论什么orm还是jdbc，这个业务复杂度都是一样的。

4.所以在这种前提下，后期打印出来的sql如果再出问题，就基本上就是由于hibernate使用不当造成的，设计上没问题都好解决。

俺不能同意你更多 ;p

我的意思是，ibatis开发过程中如何和DBA沟通，hibernate也是一样的，开发人员当然是和DBA讨论sql，不可能让dba去学hql。

（当然这里隐含的条件是，开发人员对sql必须要有基本的掌握）

就性能再说，增删改，就是单条sql，数据量大这个是dba负责分析的东东。
只要阐述业务逻辑即可，不需要把sql打印出来

优化的地方在于复杂查询，我认为这方面hibernate没什么优势，或者用ibatis或者jdbc直接上。

倒是n+1查询等等造成的性能问题，需要j2ee端人员对hibernate要掌握精深才行

hibernate相对比较难以调试的地方就在于他的n+1

比如某个操作缓慢，要从满屏的sql中寻找出执行缓慢的sql不太轻松。

找慢的sql先找DBA去抓DB中情况分析，个人经验。

1.对于部分复杂查询，hibernate直接用sql也是超简单的。

2.你这样说话是误导别人，只要对hibernate的查询部分、数据抓取策略研究一下即可，谈不上什么掌握精深。

3.我们公司用ibatis，照样天天有新人写出N+1的程序来。

利用工具很容易打出每一句执行的时间。