Java 中的复杂 SQL 编程

[Braisdom]

复杂 SQL 没有一个明确的边界和标准，站在不同角度的人也有不的看法，从客观的角度分析，我大致整理了几点：

1 ）涉及多张表：无论是 join 、union 、subquery 、以及 exists 语法结构中，多张表组合查询实现一项业务目标

2 ）动态化：整个 SQL 语句会根据参数的不同构造不同的过滤条件或 join 不同的表

3 ）复杂表达式：在数据统计领域，时常会出现各种数学计算的表达式，不仅复杂，而且多，例如：大量 case when 、类似同环比计算、以及窗口函数内的计算等

肯定有人会问，为什么要分清复杂 SQL 和简单 SQL ？道理很简单，简单的 SQL 我们通过字符串形式的编程可以解决，也容易维护，但复杂 SQL 通过字符串的形式进行编程，不仅容易出错，长期而言维护成本非常高。

无论是简单 SQL 编程，还是复杂 SQL 编程，ObjectiveSQL 都提供了近乎完美的解决方案，有兴趣的可以了解一下。

github: https://github.com/braisdom/ObjectiveSql 800+ stars

[gowk]

这一波推广 666

[Braisdom]

@gowk 总是需要一些干货的，兄弟支持一下

[lower]

ky 一下，看了你网站介绍示例里的复杂 sql 的处理，
我觉得还是直接简单查询数据到内存，然后用代码处理更方便灵活。。。

[Braisdom]

@lower 简单 SQL 更方法，不需要写代码

如果数据都在内存里，保持内存与数据库的一致性需要挑战的

[WhereverYouGo]

额 对比 Mybatis 和 Spring Data JPA 有啥优势呢

[dfzj]

ORM 其实没啥必要，现在都可以直接写 SQL 开发系统了：wuyuan.io

[Braisdom]

@dfzj 场景不一样，如果你的系统里有 300 条 超过 500 行的 SQL，你就会放弃写 SQL 的想法了

[Braisdom]

@sweetsorrow211 MyBatis 和 JPA 比我成熟，但从易用的角度讲，ObjectiveSQL 远远超越他们，现在需要的是时间和各多人尝试

[kingfalse]

互相安利可还行

[Braisdom]

@kingfalse 可行

[dfzj]

@Braisdom 那就应该存储过程了，然后直接调用存储过程。似乎这种场景下做 ORM 会更糟糕的，比如财务系统做一个期末结转操作，你会发现用 ORM 去做基本就是灾难

[Braisdom]

@dfzj 存储过程是一种方法，但单元测试怎么做，版本管理怎么做呢？

[Braisdom]

@dfzj ORM 只是一种 SQL 的代替方案，用 Java 的方法写 SQL，完全等价于你写 SQL，从而代替 SQL 的动态化

[dfzj]

@Braisdom 存储过程的测试和管理由数据库管理软件来做 等价于 测试 Java 程序的 eclipse IDE

[dfzj]

@Braisdom 等价是必须的，功能上如果有缺失，那就是没得选了，实际上只有合适不合适而已。但实际情况是，一条 SQL 内，涉及到主从多表关联的情况 ORM 是很难受的。
另外，别说 300 行 SQL 。完成一个 30 行的 SQL 事务，彼此上下文依赖的话，b 如果用 JAVA ORM 来做，明显 JAVA 程序跟数据库之间 30 次 IO 。用存储过程就一次了。
业务系统做得多了，就知道，本质就是 SQL 的执行。

[Braisdom]

@dfzj 存储过程在某些场景下是有优势的，

大部分场景下 SQL 是以查询为主，也就不存在事务的问题，我的框架只是让 Java 实现一个等价的 SQL 查询。

[dfzj]

@Braisdom 嗯嗯，适合互联网应用

[Braisdom]

@dfzj 普通的应用系统都可以使用的