JOOQ 与 SQL 查询

Question

我现在正在使用 jooq 查询...我觉得 SQL 查询看起来更具可读性和可维护性，以及为什么我们需要使用 JOOQ 而不是使用 native SQL 查询。

有人可以解释一下使用相同的原因吗？

谢谢。

Answer 1

以下是使用 native (基于字符串的)SQL 永远无法获得的最高值(value)主张:

• Dynamic SQL这就是 jOOQ 真正擅长的。您可以根据用户输入、配置等动态编写最复杂的查询，并且仍然确保查询能够正确运行。
• 动态 SQL 的一个经常被低估的效果是，您可以将 SQL 视为代数，因为不必编写难以编写的原生 SQL 语法(包含所有关键字和奇怪的括号规则等)。 ，您可以根据表达式树进行思考，因为您正在有效地为查询构建表达式树。这不仅允许您实现更复杂的功能，例如 multi tenancy 的 SQL 转换或row level security ，但每天都会出现类似transforming a set of values into a SQL set operation这样的事情
• 供应商不可知。一旦您必须支持多种 SQL 方言，手动编写 SQL 几乎是不可能的，因为方言之间存在许多细微的差异。 jOOQ 文档说明了这一点，例如与 LIMIT clause 。一旦遇到这个问题，您就必须使用 JPA(受到严格限制的查询语言:JPQL)或 jOOQ(在 SQL 使用方面几乎没有限制)。
• 类型安全。现在，当您编写 View 和存储过程时，您也将获得类型安全，但很多时候，您希望从 Java 运行即席查询，并且无法保证表名、列名、列数据类型或语法当您以基于字符串的方式执行 SQL 时的正确性，例如使用 JDBC 或 JdbcTemplate 等。顺便说一句:jOOQ 鼓励您使用尽可能多的 View 和存储过程。它们非常适合 jOOQ 范式。
• Code generation 。这会带来更多的类型安全性。您的数据库架构将成为客户端代码的一部分。当您的查询不正确时，您的客户端代码将不再编译。想象一下，有人重命名一列，却忘记重构使用该列的 20 个查询。 IDE 仅在第一次编写查询时提供一定程度的安全性，当您重构架构时它们不会为您提供帮助。使用 jOOQ，即使您的构建失败，您也可以在投入生产之前解决问题。
• 文档。生成的代码还可以充当架构的文档。对表、列的注释会变成 Javadoc，您可以用客户端语言进行内省(introspection)，而无需在服务器中查找它们。
• 使用 jOOQ 数据类型绑定(bind)非常简单。想象一下使用一个包含数百个 stored procedures 的库。您不仅能够安全地访问它们的类型(通过代码生成)，就好像它们是实际的 Java 代码一样，而且您不必担心将每个输入和输出参数绑定(bind)到类型的繁琐且无用的事件和值(value)。

从上面派生出大量更高级的功能，例如:

• parser 的可用性因此 translating SQL 的可能性.
• 架构管理工具，例如 diffing two schema versions
• 基本的 ActiveRecord 支持，包括一些不错的东西，例如 optimistic locking .
• Synthetic SQL features像type safe implicit JOIN
• Query By Example .
• 一个nice integration in Java streams或reactive streams .
• Some more advanced SQL transformations (这是正在进行的工作)。
• Export和 import功能
• 简单 JDBC mocking functionality ，包括file based database mock .
• Diagnostics

而且，如果您偶尔认为使用普通 native SQL 做某事要简单得多，那么只需:

• Use plain native SQL, also in jOOQ

免责声明:由于我为供应商工作，我显然有偏见。