jOOQ 项目存在的原因 已翻译 100%

oschina 投递于 2013/02/22 23:28 (共 5 段, 翻译完成于 02-23)
阅读 9139
收藏 26
5
加载中

Featured article by oschina reproduced with permission by Data Geekery GmbH.
English content copyright © 2013 by Data Geekery GmbH.

以下段落摘自 jOOQ用户手册的前言部分。值得思考的是,为什么你应该(或者不应该)在某特定项目中使用JOOQ。具体讲,你可能正要从jOOQ 和JPA,或者jOOQ和Hibernate,或者jOOQ和QueryDSL、或者jOOQ和SLICK(对Scala而言)的两者之中选择其一。这里给出一些指导原则(当然会稍微有点偏向JOOQ):

fbm
fbm
翻译于 2013/02/22 23:51
1

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来填补这一空白。

fbm
fbm
翻译于 2013/02/23 00:43
1

jOOQ存在的理由 —— 同LINQ相比

为了更好地将查询作为一个概念集成到编程语言当中,其它的平台采用了LINQ (同LINQ-to-SQL一起), Scala用的是SLICK,Java也采用了QueryDSL。通过查询,它们可以理解对任意目标的查询,这些目标可以是SQL、XML、集合(Collection)以及其它的异构数据存储(Data Store)。JOOQ断言,这样也是走错了方向。

在比较高级的查询用例中(比简单的CRUD和少量的多表查询高级),人们还是希望能够从SQL较强的表达能力中获益。SQL本身的关系型特质,使得它和C#、Scala或者Java等等这类面向对象语言和非完全函数式编程语言能够做到的事情相比,差别巨大。

fbm
fbm
翻译于 2013/02/23 01:08
1

要用形式化的方式表达和验证它们产生的多表查询和临时表(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来填补这个空白。

fbm
fbm
翻译于 2013/02/23 01:44
1

jOOQ很不同

SQL从来就不是一种抽象的语言。它不局限在重量级的映射器这样狭小的范围之内,也不隐藏关系型数据的美以及简单性。SQL一直都不面向对象。SQL从来就不是SQL之外的任何其它东西!

fbm
fbm
翻译于 2013/02/23 02:03
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(14)

youpengfei
youpengfei

引用来自“思无疆”的评论

同感。
现在的众多的ORM已经让很多年轻的程序员,不再关心表结构,不再关心数据建模,不再关心查询的优化,长久下去,对程序员的综合能力是一种损害。
不是这个原因吧,jooq 能够实现很复杂的sql 而且通过更直接的方式。jpa则要绕很大的弯来完成。用了很久jpa发现jpa的场景太理想化了,现实比其要险恶的多。所以mybatis才有一席之地,但是mybatis分离了java和sql让查错变得有些困难了
新人王
新人王
看好看好!!!!
冬日暖阳85
冬日暖阳85

引用来自“wkh”的评论

我认为,过分隐藏SQL是不利的,我们在使用Nhib时,还时要使用SQL的否则性能太低了,

我认为ORM最好只做,增加,修改、删除等操作,至于查询,还得使用SQL

赞同
c
code_cj

引用来自“wkh”的评论

我认为,过分隐藏SQL是不利的,我们在使用Nhib时,还时要使用SQL的否则性能太低了,

我认为ORM最好只做,增加,修改、删除等操作,至于查询,还得使用SQL

同感
wkh
wkh
我认为,过分隐藏SQL是不利的,我们在使用Nhib时,还时要使用SQL的否则性能太低了,

我认为ORM最好只做,增加,修改、删除等操作,至于查询,还得使用SQL
思无疆
思无疆
同感。
现在的众多的ORM已经让很多年轻的程序员,不再关心表结构,不再关心数据建模,不再关心查询的优化,长久下去,对程序员的综合能力是一种损害。
醉了时光
醉了时光

引用来自“Wendal”的评论

引用来自“wiseach”的评论

不看好,又一个轮子。

nginx是apache的轮子吗?

是,但是是个风火轮。
wendal
wendal

引用来自“wiseach”的评论

不看好,又一个轮子。

nginx是apache的轮子吗?
准码农
准码农
mark
wiseach
wiseach
不看好,又一个轮子。
返回顶部
顶部