这是一个创建于 1776 天前的主题，其中的信息可能已经有所发展或是发生改变。
复杂 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
 | 1 gowk 2020-12-07 13:57:56 +08:00 via Android  3 这一波推广 666 |
 | 3 lower 2020-12-07 14:17:17 +08:00 ky 一下，看了你网站介绍示例里的复杂 sql 的处理， 我觉得还是直接简单查询数据到内存，然后用代码处理更方便灵活。。。 |
 | 5 WhereverYouGo 2020-12-07 17:28:14 +08:00 额 对比 Mybatis 和 Spring Data JPA 有啥优势呢 |
 | 8 Braisdom OP @sweetsorrow211 MyBatis 和 JPA 比我成熟，但从易用的角度讲，ObjectiveSQL 远远超越他们，现在需要的是时间和各多人尝试 |
 | 9 kingfalse 2020-12-07 20:47:21 +08:00 via Android 互相安利可还行 |
 | 11 dfzj 2020-12-07 21:51:43 +08:00 @Braisdom 那就应该存储过程了，然后直接调用存储过程。似乎这种场景下做 ORM 会更糟糕的，比如财务系统做一个期末结转操作，你会发现用 ORM 去做基本就是灾难 |
| 13 Braisdom OP @dfzj ORM 只是一种 SQL 的代替方案，用 Java 的方法写 SQL，完全等价于你写 SQL，从而代替 SQL 的动态化 |
| 15 dfzj 2020-12-07 22:34:19 +08:00 @Braisdom 等价是必须的，功能上如果有缺失，那就是没得选了，实际上只有合适不合适而已。但实际情况是，一条 SQL 内，涉及到主从多表关联的情况 ORM 是很难受的。 另外，别说 300 行 SQL 。完成一个 30 行的 SQL 事务，彼此上下文依赖的话，b 如果用 JAVA ORM 来做，明显 JAVA 程序跟数据库之间 30 次 IO 。用存储过程就一次了。 业务系统做得多了，就知道，本质就是 SQL 的执行。 |
| 16 Braisdom OP |
Select Language