JOOQ与SQL查询

Question

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

有人可以解释使用它的原因吗？

谢谢。

Answer 1

以下是原生（基于字符串）SQL永远不会获得的最高价值主张：

• Dynamic SQL是jOOQ真正擅长的领域。您可以根据用户输入，配置等动态组成最复杂的查询，但仍要确保该查询将正确运行。
• 动态SQL的一个经常被低估的事实是，您将SQL视为代数，因为它不必编写难以编写的本机SQL语法（带有所有关键字和怪异的括号规则等）。 ，您可以根据表达式树来思考，因为您正在为查询有效地构建表达式树。这不仅使您可以实现更复杂的功能，例如对multi tenancy或row level security的SQL转换，而且每天都可以实现transforming a set of values into a SQL set operation
• 供应商不可知性。一旦您必须支持多个SQL方言，由于方言之间的许多细微差别，手动编写SQL几乎是不可能的。 jOOQ文档对此进行了说明。 LIMIT clause。一旦遇到问题，就必须使用JPA（受限制的查询语言：JPQL）或jOOQ（对于SQL使用几乎没有限制）。
• 输入安全性。现在，当您编写视图和存储过程时，也将获得类型安全性，但是很多时候，您想从Java运行即席查询，并且不能保证表名，列名，列数据类型或语法以基于字符串的方式执行SQL时的正确性，例如使用JDBC或JdbcTemplate等。顺便说一句：jOOQ鼓励您使用任意数量的视图和存储过程。它们非常适合jOOQ范例。
• Code generation。这带来了更多的类型安全性。您的数据库架构成为您的客户端代码的一部分。查询不正确时，客户端代码将不再编译。想象有人重命名一列而忘记重构使用它的20个查询。 IDE只能在第一次编写查询时提供一定程度的安全性，而在您重构架构时它们不会为您提供帮助。使用jOOQ，您的构建会失败，并且可以在投入生产之前很长时间就解决问题。
• 文档。生成的代码还充当架构的文档。在表上的注释，列会变成Javadoc，您可以使用客户端语言对其进行自省，而无需在服务器中查找它们。
• 使用jOOQ，数据类型绑定非常容易。想象一下使用{s {3}}的100个库。您不仅可以安全地（通过代码生成）访问它们的类型（就像它们是实际的Java代码一样），而且您不必担心将每个单独的in和out参数绑定到类型的繁琐和无用的活动和价值。

从上述内容中衍生出许多更高级的功能，例如：

• stored procedures的可用性以及因此parser的可能性。
• 架构管理工具，例如translating SQL
• 基本的ActiveRecord支持，包括一些不错的功能，例如diffing two schema versions。
• 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

而且，如果您偶尔认为使用普通的本机SQL要做的事情要简单得多，那就：

• Diagnostics

免责声明：在为供应商工作时，我显然有偏见。