@zhangysh1995 感谢支持

@hangs 如果不涉及复杂 SQL，你可参考一下我 git 文档里的描述，自动代码生成相比其它 ORM，优势自已体会一下，我说再说也不没有说服力。

@Cbdy 问题领域的复杂度是无法避免的，所以需要通过 Java 去避免复杂度的蔓延

@hangs 兄弟，插件是必须的，由于 IntelliJ IDEA 的 Java 语法检测太严谨，我已经提了 issue 给他们了，说是会有改进，我是自动生成 java 代码，没有 IDE 的支持很难完成。

@beginor 非常认可你的说法，没有大公司的背书，项目很难起来。

@vipcc 感谢，我会参考一下，前面已经有好几位兄弟介绍了。

@felixcode 你说的其实一个 SQL 性能测试引擎，完全做到很难，毕竟场景太复杂，但随着不断的迭代，能够避免大量 SQL 的错误，这是我下一阶段工作的重点。

@Cbdy 你说的很对，SQL 的复杂度相比其它是高出很多，但从抽象的角度去看，它就是一种协议，只不过这种协议承载了较多关系型数据的计算逻辑和统计方式而已。

我只是做了一个类比，传输层协议更多是定义结构，其内存的逻辑更多是由程序控制的。

数据库设计的初衷就是为了封装数据的计算逻辑，降低外部应用程序的复杂度，提供简单的交互协议实现数据计算，但随着数据统计方式的发展，问题领域的复杂度变化，传统的方式编写 SQL 已经很难满足分析需求了，只就需要逻辑型编程语言提供封装，隐藏复杂的构造过程。

@mumubin 很多人都有你这样的想法，slow sql 也是我下一阶段需要解决的，如果通过单元测试排查一部分常见的问题。

@Cbdy 要从不同的角度去理解 SQL，SQL 其实和 HTTP，SMTP 这类协议一样，只不过 SQL 是解决 Java 与数据库交互的一种协议，我相信你不会手动编码去实现 HTTP，SMTP 这类协议的，都是通过更高层的封装去访问，当然如果做更底的编码，还是会涉及的。

@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 本质上是一个关系数据库的计算引擎，做的很不错，后面我也会集成进我的项目，实现异构数据源的计算。