以下段落摘自 jOOQ用户手册的前言部分。值得思考的是，为什么你应该（或者不应该）在某特定项目中使用JOOQ。具体讲，你可能正要从jOOQ 和JPA，或者jOOQ和Hibernate，或者jOOQ和QueryDSL、或者jOOQ和SLICK（对Scala而言）的两者之中选择其一。这里给出一些指导原则（当然会稍微有点偏向JOOQ）：
jOOQ存在的理由 —— 同JPA相比
Java和SQL在一起使用已经有很久了。SQL是一种很“古老”但很完备的技术，大家对它的理解也已很透彻。虽然在Java的运行平台JVM之上也能建立一些新式的当代语言，但Java语言可也不算新了。然后，经过了这么多年，处理SQL和Java二者之间接口的库（Library）不断变来变去，只留下了JPA这个大家勉强在半信半疑中接受的一个标准， 几乎没留下任何别的选项。
迄今为止，能够真正把SQL看做编程语言当中具有首要地位的数据库抽象框架或库，少之又少。包括业界标准JPA, EJB、Hibernate、JDO、Criteria Query以及其它很多在内的框架，为将SQL的使用范围缩减到最小采用了JPQL、HQL、JDOQL以及其它各种各样的低级查询语言，它们都是在企图隐藏SQL本身。
jOOQ来填补这一空白。
jOOQ存在的理由 —— 同LINQ相比
为了更好地将查询作为一个概念集成到编程语言当中，其它的平台采用了LINQ (同LINQ-to-SQL一起), Scala用的是SLICK，Java也采用了QueryDSL。通过查询，它们可以理解对任意目标的查询，这些目标可以是SQL、XML、集合（Collection）以及其它的异构数据存储（Data Store）。JOOQ断言，这样也是走错了方向。
在比较高级的查询用例中（比简单的CRUD和少量的多表查询高级），人们还是希望能够从SQL较强的表达能力中获益。SQL本身的关系型特质，使得它和C#、Scala或者Java等等这类面向对象语言和非完全函数式编程语言能够做到的事情相比，差别巨大。
要用形式化的方式表达和验证它们产生的多表查询和临时表（ad-hoc）的表达式的类型非常困难。要想支持类似数据透视表（Pivot Table）、非巢套式游标（Unnested Cursor）或者仅仅是从派生表中进行任意投射（Projection）等等这样高级的表表达式，那就更加是难上加难了。如何在非常强的面向对象类型模型之中实现这些特性，不太可能会在考虑范围之内。
本质上讲, 决定创建看上去跟SQL或者C#或者Scala、Java很像的API，就是一种确定无疑的或者偏向这个或者偏向那个平台的决定。尽管让SLICK以和LINQ（或者Java世界里的QueryDSL）类似的方式进行演进比较容易， 但是随后，用以清晰表达其背后意图的SQL特性范围（Feature Scope）就很难再添加进来了（比如，你怎么来对Oracle的分区外联语法进行建模？如何对ANSI/ISO SQL:1999中的分组集（Grouping Set）进行建模？怎样才能支持标量子查询缓存？等等问题）。
jOOQ来填补这个空白。
jOOQ很不同
SQL从来就不是一种抽象的语言。它不局限在重量级的映射器这样狭小的范围之内，也不隐藏关系型数据的美以及简单性。SQL一直都不面向对象。SQL从来就不是SQL之外的任何其它东西！
