一个关于Hibernate的优化实例：从HQL到QBC，从QBC到QBE，再到“增强的”QBE

我记得我发帖询问的时候有人给我回复个别人写的类支持这个
但是好像还是有点问题 
再观察观察

我就是吧文档翻了一下  发现确实没有having子句

个人认为Hibernate新版中要加入此类功能应该没什么难度的，怀疑他们自己都放弃了QBC，所以对QBC不报升级的希望，如果是简单查询无所谓，复杂查询还是hql。

从业务上来讲，针对某个页面或者需求的复杂hql就是应该单独处理的。

ibatis王者, hibernate在大系统中会死人的，很难调忧的
特别是那些做网站的，需要做集群的，不要动不动就Hibernate，别以为做测试时几千条上万条数据跑得挺快的，要是真的数据量上来了根本撑不住，没法忧化。

ibatis绝对会更适合你的，再者比hibernate也简单，何乐而不为呢。。。。

不知道你是怎么比较的,拿点实在的东西出来,别说这么空洞的话,你到底能说服谁?

我在公司项目中指定的规范就是禁止直接使用HQL，而使用 named sql。
两个原因：
1. sql开发调试更方便，灵活；hql很多sql标准功能无法实现，而且复杂的查询要转化为hql煞费功夫
1. Java代码和 数据库查询语句分离开发，增加易读性，改进维护难度；

那是你们公司特定的环境下的规定，像我们公司的产品必须要跨数据库，就肯定不能用named sql。

很多情况下，为了避免重复需要动态拼sql（hql），这部分的逻辑总得有个地方要放，我不认为放在配置文件中是个好主意，比如iBatis中的判断逻辑判断语法，配置文件和代码文件应该同等对待，都是代码，IDE对配置文件的感知能力是远不如代码文件的。

Java代码根据规范，组织好分层和代码的规范，一样可以分离开发，提高易读性和改进维护难度。
相反，配置文件的规模（行数和文件数和配置文件中的逻辑判断）达到一定程度一样是问题，本质上来讲这个复杂度是不可避免的，你总得找个地方放这些逻辑，不管是在代码、配置文件、存储过程，都一样的。

   想听听你们项目跨数据库的需求和架构是怎样的。
   我几年前公司的项目也是要求跨数据库，因为当时的集团管理软件是一个通用产品，而客户可能选用不同的DB，当时也对这种通过Java代码实现复杂查询逻辑以达到通用化目的设计模式深信不疑，顶礼膜拜。
    本来当初的Ofbiz框架对类似HQL功能的支持比hibernate完善的多，但发现过于复杂的查询，如统计，报表，分析等，编码式查询逻辑始终无法实现，最终不得不用 native  sql 。跨数据库解决方法是，针对Oracle，DB2等客户可能用到的db专门做sql调整。也就是有两个DB的 sql 实现。
     使用Hibernate类似。我的经验是，HQL无论多强大，始终有native sql 做不到的，最后不能不使用 sql。

很简单，过于复杂的查询本来就不应该用同样的框架去做。
1.首先从商务上，我们公司会把这方面的需求转到BI上来做，数据仓库部门和数据挖掘部门是我们公司比较强的地方。
2.如果复杂度没有到BI这一层面的话，或者说必须要用Java来做的话，统计报表本来就应该单独设计，至于这部分的实现是不是用Hql还是本地sql可以另讨论，但是不要把统计报表类的需求延展到其他事务操作型的需求上。
3.我们的产品正好没有什么统计报表的需求，我也建议统计报表类的需求实现单独讨论比较好。

通读了这个主题所有的主题后，实在是忍不住了，呵呵，我也来说一句：
1、框架用来处理业务逻辑。
2、所有涉及到对数据库的SQL操作，我喜欢通过写存储过程和触发器来
解决，不管你的SQL有多复杂。如果你要求灵活，就用带不定参的存储过
程；如果你要求动态，可以在存储过程中用动态sql；如果你要求性能，
可以调优存储过程嘛。
3、java代码中就用一行代码调用一下存储过程就好了，这样java代码的
可读性才高嘛。最后说一句，使用存储过程来解决复杂的sql操作的效率相
当于两点之间线段最短，而用java代码来包了一层又一层什么的，相当于绕
了一个很长的弧线。