对于子查询器 - 什么是好的？ HQL 或标准 -DetachedCriteria答案

【问题标题】：For Subqueriers - What is good? HQL or Criteria -DetachedCriteria对于子查询器 - 什么是好的？ HQL 或标准 -DetachedCriteria
【发布时间】：2012-01-16 10:26:58
【问题描述】：

考虑以下查询。

SELECT * FROM T1 WHERE T1.id = (SELECT id1 FROM T2 where T2.id1 = (SELECT id2 FROM T3))
 AND T1.anotherId IN (SELECT id3 FROM T3);

我猜 HQL 比使用带有 DetachedCriteria 的 Criteria API 更有效？

我已经在我的项目中实现了（大部分）标准，它看起来很 OOP。对眼睛也更容易（这取决于感知）

想法？

【问题讨论】：

这不是一个建设性的问题。
这个查询可以在没有任何单个子查询的情况下使用连接重新实现。 HQL 和标准不应该有任何区别：大部分时间都花在执行查询和获取结果上，无论您使用什么来构建查询。如果您和您的同事发现标准比 HQL 更具可读性（我不同意），请使用标准。
效率在什么方面？ a）要写入的字符，b）执行时间，c）解析时间？ HQL 在 a) 中明显获胜，但 b) 和 c) 应该几乎相等
要写的字符，是的。但我本以为它也会在解析时间上获胜。可能是我错了。 JB ，是的，我是用连接写的。 dev.mysql.com/doc/refman/5.0/en/rewriting-subqueries.html

标签： java hibernate criteria-api

【解决方案1】：

对于复杂的查询，我更喜欢使用 Criteria API。

当您编写 JPQL/HQL 查询时，您只能靠自己。在某些情况下（我并不是说这是您的情况），Criteria 可能会生成更好、更优化的查询。

我一直使用这个规则：

如果查询足够简单 - 使用 JPQL
如果它很复杂 - 使用 Criteria
如果对于 Criteria 来说太复杂 - 关于存储过程或重新设计的事情

【讨论】：

这与我应用的策略相同。 3号除外。我会尽量远离SP。如果数据库交给你，你可以重新设计的只有这么多。如果必须使用 DetachedCritera，您会采用什么策略？我用 HQL 写的。
为什么需要 DetachedCriteria？您是否需要在事务/会话上下文之外准备查询？