@uptonking 是的，只有经得起大家挑战的项目才有生命力，总是靠人扶肯定长不大的。

@Cbdy 很多应用都会有报表的，只是多少的问题，Java 的代码可以成千上万行，有语法层结构化的形式进行管理，同样也存在很多模式和规范，这块在 SQL 上就很少了，SQL 的工程化能力远远不如 Java 。

所以通过 Java 的形式去写 SQL 是很必要的，但 SQL 已经诞生了很多年，而且被很多人所接受，如果设计一套全新的语法模式，大众很难接受，这样项目的生命力也不强，所以我尽可能的让 Java 代码接近 SQL，符合大众的味口，哈哈。

“Dynamically SQL programming with Java syntax, and very close to SQL syntax”

我之前设计过一个语言，我称它为 JDS(Java Database Script) 后来放弃了，在我的 github 也有。

@Cbdy 其实很多人都有你这样的想法，我前期遇到很多这样的想法来挑战 ObjectiveSQL，喜欢与不喜欢是很主观的，我也不参与这样的争论，就像争论哪种编程语言好一样

我们需要更客观一点看，有的公司 SQL 多，有的公司 SQL 少，有的复杂，有的相对简单，这样的背景下在选择工具时就会有不同的想法。

我是经历过一个项目中存在 500 - 1000 条长度超过 400 行的 SQL，平均每个 SQL 需要 JOIN 20 张表或子查询（有较多重复），在这样的场景下 SQL 的维护成本，修复 Bug 的成本，单元测试的成本是巨大的。

这些经历导致了我的项目的出现，当然 @Cbdy 你可能有不一样的背景。

@beginor Jinq 和 ObjectiveSQL 有点类似，但还是有本质的区别，
1 ） Jinq 的表达式依然是 Java 基础表达式形式，也就是只能按 Java 规范进行表达式计算，但在 SQL 中通常会遇到函数调用后的表达式计算
2 ） Select 和 Where 是通过 lambda 解析实现，代码表现力差太多了

@beginor 是的，SQL 历史已经很长，新型技术完全替代，可能需要很长的时间，甚至需要的是一代人。
我们的脑子里要有两个世界，一个是客观存在的世界，一个是我们主观认为的一种世界（也就是世界应该怎么样）。

有时主观认为的世界里有一些正确的事情，客观世界里不一定接受，随着技术的进步，有可能被超越，也有可能在若干后成为主流。

@Pursue9 认可你的想法，数据分析只是一个问题域，SQL 只是一个协议，我们访问网络时，完全不知道它底层的结构，我们在做 HTTP 应用时，基本也不会接触 HTTP 协议本身，统计和分析数据理论上也应该一样的方式进行演进。

@comsweetcs 思考的角度不一样，处理的问题域不一样，对工具的选择就会不同，我们需要更客观的分析

@dswyzx DBA 和程序员的职责不一样，面对的问题域也不一样。
DBA：通常面对的是静态问题，考虑的场景也比较单一，用 SQL 作为工具是比较合适，无论是优化，还是维护 SQL 可能是最价的选择，就像脚本型语言是 运维工程师的最爱。

程序员：通过面对的是动态问题，一段含有 SQL 和 Java 的代码逻辑需要满足很多场景，各种奇怪的使用方式，SQL 的构造过程也非常复杂，此时 SQL 语法逻辑和表现力就够用了，如果是纯粹的字符串拼接，也会让程序员崩溃，简单的还好，真复杂起来解决 Bug 的成本 就很高了。

@Betsy Calcite 在我们公司里用了，linq4j 和我的差别很大的，它只是 Java8 Stream 中的扩展，只是对内存中的数据进行过滤和计算，Calcite 本质上是一个关系数据库的计算引擎，做的很不错，后面我也会集成进我的项目，实现异构数据源的计算。

@xiangwan jooq 我参考过，看过它的代码，设计理念很好，但程序设计一般，不够灵活，最关键是的它的代码需要手动生成，每次调整完之后，都得生成一下代码才能编译通过，好麻烦。

SQL 语言设计的初衷是为数据分析人员提供的一种语言，比较接近自然语言，但和逻辑型编译语言结合不是很友好，
目前所有逻辑型编程语言里，都是以字符串的形式存在。

其实回归本质，Java 语言是一门高度抽象的语言，它可以解释一切知识领域，数据库只是一个领域而已，如果没有 SQL 你会怎么设计，怎么样用面向对象的方式设计数据库的访问。

第一性原理，我设计时，先参考现有的知识，然后再忘掉所有的知识，它原本应该怎么样。

@abcbuzhiming 我要解决的问题如下：
1 ）重用性，一个复杂查询中经常会多次 JOIN 同一张表，只有少量变化，SQL 无法解决，只通过通过过程化编程语言解决，Java 只是一种选择而已。
2 ）动态性，一个复杂查询中会根据参数不一样，JOIN 不同的表 /子查询，投影不同的字段，当然 Where 后的表达式会有较大的变化。
3 ）单元测试，一个复杂 SQL 拆分成多个过程，针对过程进行单元测试，而不是一条非常复杂的 SQL 进行测试

@fafa2npu 我仔细研究一下 LINQ，要看最终执行的 SQL 是什么，可以参考一与它的实现原理。其实动态 SQL 只是其中一部分特性

社区的建设也在准备中，希望更多兄弟参与进来，后面我也将内部的技术原理整理并分享出来。里面的骚操作比较多，不是很常用，缺很实用。

@renyijiu 现在有 4，5 个公司在用，毕竟刚刚发布 2 个月左右，问题肯定比较多，我也会及时修复的。

@huskar kotlin 和 Scala 很容易的，语言自身就支持运算符重载的。

@nannanziyu 兄弟，那是对已经出来的数据进行过滤，而不是在 SQL 中过滤的，

@kingfalse 两者不会冲突，Lombok 有人爱，有人恨，很正常的，就像 Java 一样，你可以爱他，也可以恨他。

@vone 兄弟我还真看过，Entity Framework 针对 比较运算符和逻辑运算符是无法支持的，例如

SELECT * FROM Orders WHERE OrderID > 10 AND Freight = 1

这类写起来太复杂了。

在 ObjectiveSQL 中，缺很方便。

select.where( order.orderId > 10 && order.freight.eq(1) )

@shade apijson 好像不是同一类东西