目录

    • 长SQL有什么危害？
    • 怎么办？
      • Java
      • Python
      • Scala
    • SPL
      • 常规计算能力
      • 超越SQL的能力
      • 应用集成、低耦合与热切换
    • SPL资料

我们工作中写SQL处理数据是家常便饭，不管是应用内数据处理还是临时查询分析都可以用SQL完成，相对其他技术（如Java等高级语言）也更简单。不过，SQL的简单只限于简单需求，有些复杂计算场景SQL写起来却很难，嵌套N层以至于达到几百上千行，说SQL代码长度时通常不会以行计而是以KB计。这种情况并不少见，相信经常写SQL的小伙伴并不陌生。

为什么会出现这种情况呢？在http://c.raqsoft.com.cn/article/1639032922105 里详细分析了这个问题。虽然SQL比其他数据处理技术更简单，但仍存在一些短板（如缺乏有序支持、集合化不彻底、没有高级语言的对象引用机制等），导致复杂计算用SQL表达出来很繁琐。这种既复杂又很长的SQL会带来很多问题。

长SQL有什么危害？

复杂长SQL给我们带来的第一个困扰是难写。

其实，代码长本身还不是大问题，很多任务步骤多也就会写得长，但并不难。而SQL的长，常常是伴随着难，而且会随着长度增加变得异常难。SQL在解题时很绕（思维方式上的难），你没法按照正常思路去实施算法，明明想出一个好的解法，简单一二三四步就完成了，但用SQL就要绕来绕去，不嵌套几层写个几十上百行好像体现不出你水平一样。而且不光嵌套子查询，复杂SQL还伴随多表关联和各种过滤条件，写的时候要保持头脑异常清醒，一旦写错不仅很难定位，有时还会把数据库跑死。这当然跟SQL不提倡过程（CTE语法提供了一定支持）有关，一个任务写100行代码，分成 100 个语句还是只有 1 个语句，其复杂度完全不是一个层面的。

另外，写代码还离不开调试，而SQL的调试功能可谓难用至极。直到今天各大数据库都没提供像样的调试功能，相比其他高级语言的开发调试环境简直不忍直视。一句嵌套N层的长SQL发现写的不对只能把子查询从长语句里一层一层摘出来单独执行调试定位，费时费力，这更增大了SQL的书写难度。

难写就意味着开发周期长，我们写SQL都是为前端业务服务的，一个计算需求连写带调试搞个三五天甚至一周，恐怕业务时效性都没了，被怒怼也是有苦难言。

除了难写，复杂SQL还很难维护。数据处理业务的稳定性往往很差，经常要修改，不过想要修改这些SQL恐怕并非易事。别说新人接手，就是作者本人也经常出现过一段时间自己都看不懂的尴尬情况。改一个SQL跟重新写一个的时间差不多，这还玩啥。

另外复杂SQL还会影响数据库移植。虽然数据库移植不经常发生，不过一旦发生就要命。近些年随着业务的高速发展以及开源数据库的崛起，更换数据库时有发生。这就涉及到SQL迁移，我们知道数据库都是有方言的，在一个数据库上使用的函数到另外一个数据库未必管用，而且各类数据库对SQL标准的支持程度不同（如Oracle窗口函数支持的很好，其他数据库就要差很多），这些“特殊的”内容夹杂在复杂SQL里就很难实现数据库迁移了。

不管怎样，复杂SQL都是数据开发人员的噩梦。

怎么办？

SQL难的问题可不是第一天出现，大家也都在积极寻找解决办法。其实现在很多开发方法已经不再推荐写复杂SQL，像ORM技术算是革掉SQL半条命，而微服务等框架更是要求SQL仅仅用于完成基本的数据读写，而不能用于做复杂计算和业务处理。这些方法的思路很清晰，即把SQL的应用局限于基本的读写任务，在应用端完成复杂的数据处理和业务逻辑，这样就可以规避SQL的那些问题，架构上也更符合现代应用的需要。

不用SQL，那些复杂的计算和业务逻辑该用什么技术来做呢？

当然只能是其它程序语言了，几乎所有应用级程序语言都可以指挥SQL工作，实现这种开发架构不是问题。那么，这个问题是不是就被轻易解决了？

我们来考察一下这些常用的技术。

Java

Java肯定是第一选择，毕竟众多应用程序都是Java开发的，如果能搞定这些数据处理就会有很多优势。Java天然支持过程计算，实现复杂计算时虽然代码可能更长，但可以按照正常思维实现算法，这样是不是就可以替代SQL了？

No，没有这么简单。

由于Java缺乏专业的结构化数据对象，缺少来自底层的有力支持，在实现SQL这类的复杂计算时并不容易。

结构化数据计算的返回值的结构随计算过程而变，大量的中间结果同样是动态结构，这些都难以事先定义，而Java是强类型语言，又必须事先定义数据对象的结构（否则只能用map这类操作繁琐的数据对象），这就使Java的结构化计算僵化死板，lambda语法的能力严重受限。解释性语言可以简化参数的定义，函数本身就可指定参数表达式应解释成值参数还是函数参数，而Java是编译型语言，难以区分不同类型的参数，必须设计复杂的接口才能实现匿名函数（主要指lambda语法），这连SQL程序员都不易掌握。省略数据对象而直接引用字段（比如写成”单价*数量”），可显著简化结构化数据计算，但Java缺乏专业的结构化数据对象，目前还无法支持此类表面简单实则巧妙的语法，这就使Java代码冗长且不直观（只能写成”x.单价*x.数量”）。

缺少结构化数据计算类库还会导致代码过长，同样的一个分组汇总用SQL一句就能写出来改成Java就要写几十行，这显然也对简化复杂SQL无益。这个问题即使在Java8增加了Stream后也没有明显改善，为了简化运算用Java取代SQL基本不可能（有些应用用Java做数据处理往往是由于架构上的要求，就其简便性上还远不及SQL）。

另外，Java作为编译型语言很难热部署，也就难以及时应对多变的数据计算场景。

Python

直接的Java不行，那大热的Python怎么样呢？Python+SQL可比Java+SQL容易得多了吧。

的确，Python（主要是Pandas）提供了丰富结构化计算类库，计算实现要比 Java 简单很多。不过，实际使用Pandas处理数据尤其是复杂运算时也会碰到代码很难写的情况。其实，Pandas 本来就不是为结构化数据设计的，它并不是我们熟悉的数据表（一行行数据记录的集合），而是个矩阵。用来处理结构化数据时，做些过滤合并这些简单运算还好点，碰到分组有序等复杂一些运算，就会比较麻烦了，思路上也经常要绕一下。

这还不是Python的主要问题，Python与应用结合的难点在于其集成性上。

Python很难与Java应用集成！

Python和Java集成主要有两种方式。一种是服务式调用，既然Python和Java是两套体系，那就单独部署通过服务（网络通信）的方式交互，这种方式要维护两套应用比较麻烦，还会存在一些安全认证系统权限等管理问题，而且数据交换的性能也很差，不到万不得已不会采用这种方式。另一种是使用Jython这种解释器（JVM上的Python），由于采用Java开发可以很方便与应用集成，但Jython又缺乏足够的计算库（如Pandas）很难应付那些复杂计算。无论采用何种方式，都会在应用方面产生巨大限制，导致在Java应用中用Python来实现复杂计算的可行性不高。

除非你把整个应用都用Python写，但是Java的各种企业级能力又用不上了，做做小应用还行吧。

Scala

Scala的特性与Python类似，都提供了DataFrame对象，实现简单的结构化数据计算也比较简单，作为高级语言有序、对象属性化等特性支持良好，相对Java在集合运算上也更简单。Scala运行于JVM之上，天生就容易被JAVA集成，这些都是Scala的优点。

Scala的缺点在于使用难度较大，难学更难精，用于复杂数据处理与SQL相比尤有劣势，也就不用想通过Scala简化复杂SQL了。这大概也是为什么Spark要回归SQL的原因了吧。而且，Scala作为编译型语言同样不支持热部署。

SPL

这些高级语言都存在这样那样的缺点，从简化复杂SQL的角度来看无一能胜任。那还有什么办法呢？

其实，从前面的分析中我们明显能够感受到，面向结构化数据计算尤其是复杂计算，现有技术（开发语言）都各有优缺点，SQL擅长复杂计算但对有序、过程支持不好，Java恰好反过来支持有序和过程但集合计算能力很弱。如果能综合这些技术的优点，那简化复杂SQL的目标也就达成了。

开源SPL恰好是这样一个产品。

SPL全称Structured Process Language，是一个专门用于结构化数据计算的程序语言。

常规计算能力

一致的数据类型

SPL相对Java提供了更专业的结构化数据类型，即序表。和SQL的数据表一样，序表是批量记录组成的集合，具有结构化数据类型的一般功能，可以与SQL无缝交互承接SQL的返回值。

序表支持所有的结构化计算函数，计算结果也同样是序表，而不是Map之类的数据类型。比如对分组汇总的结果，继续进行结构化数据处理。

Orders.groups(year(OrderDate):y; sum(Amount):m).new(y:OrderYear, m*0.2:discount)

丰富的计算类库

在序表的基础上，SPL提供了丰富的结构化数据计算函数，比如过滤、排序、分组、去重、改名、计算列、关联、子查询、集合计算、有序计算等。这些函数具有强大的计算能力，无须硬编码辅助，就能独立完成计算。

如组合查询：

Orders.select(Amount>1000 && Amount<=3000 && like(Client,"\*bro\*"))

内关联：

join(Orders:o,SellerId ; Employees:e,EId).groups(e.Dept; sum(o.Amount))

SPL支持简单形式的Lambda语法，无须定义函数名和函数体，可以直接用表达式当作函数的参数。修改业务逻辑时，也不用重构函数，只须简单修改表达式。SPL是解释型语言，使用参数表达式时不必明确定义参数类型，使Lambda接口更简单。比如计算平方和，想在sum的过程中算平方，可以直观写作：Orders.sum(Amount*Amount)。

同时作为解释执行语言的SPL还天然支持动态数据结构，可以根据计算结果结构动态生成新序表，特别适合计算列、分组汇总、关联这类计算。较复杂的计算通常都要拆成多个步骤，每个中间结果的数据结构几乎都不同。SPL支持动态数据结构，不必先定义这些中间结果的结构。比如，根据某年的客户回款记录表，计算每个月的回款额都在前10名的客户。

Sales2021.group(month(sellDate)).(~.groups(Client;sum(Amount):sumValue)).(~.sort(-sumValue)).(~.select(#<=10)).(~.(Client)).isect()

过程控制与SQL协同

除了提供与SQL相当的集合运算能力，SPL还对过程控制和分步计算提供了良好支持，灵活的分支判断语句、循环语句，配合专业的结构化数据对象，可以方便地实现各类业务逻辑。比如找出销售额累计占到一半的前n个大客户，可以这样分步实现：

A
1=db.query(“select client,sum(amount) amount from sales group by client order by amount desc”)
2=A1. sum(amount)/2
3=0
4=A1.pselect((A3=A3+amount,A3>=A2))
5=A1(to(A4))

通过SQL先完成分组汇总并按汇总值降序排序，然后SPL承接SQL的计算结果再通过分步方式完成后续计算，SPL与SQL有效结合，这样就很大程度达到了简化复杂计算的目标。

在应用中，SPL很多时候都要与SQL交互协同，充分发挥二者的优势，包括数据库读写、事务处理、流程处理、存储过程调用等。

数据库写入（更新/插入）：

db.update@u(A7,sales;ORDERID)

执行DML语句：

db.execute("insert into DEPARTMENT(DEPT, MANAGER) values(" />
 
SPL采用了网格式编码方式，代码不仅天然对齐层次清晰，在实施过程计算时可以直接使用格子名称来引用上一步的计算结果而不必费心定义变量（虽然也支持）非常方便。好用的开发环境自然起到事半功倍的效果，进一步简化复杂计算实施难度。
 
应用集成、低耦合与热切换
 
SPL提供了标准应用接口（JDBC/ODBC/RESTful）可以很方便与应用集成。尤其对于Java应用可以将SPL作为嵌入引擎集成，使得应用本身就具备强数据计算能力。
 
JDBC调用SPL 代码示例：
 
Class.forName("com.esproc.jdbc.InternalDriver");Connection conn =DriverManager.getConnection("jdbc:esproc:local://");Statement st = connection.();CallableStatement st = conn.prepareCall("{call splscript(?, ?)}");st.setObject(1, 3000);st.setObject(2, 5000);ResultSet result=st.execute();
同时，SPL采用解释执行机制，天然支持热切换。这样对于稳定性差、经常需要新增修改的数据处理需求非常友好。SPL脚本可以与Java程序独立，外置在Java之外，修改和维护都可以独立进行，脚本修改上传后就能实时生效，保证应用可以不中断地提供数据服务。
SPL外置算法不仅能有效降低应用与数据库的耦合性，独立的SPL模块还可以进一步降低应用各个模块间的耦合性，使得结构更为清晰，架构也更为合理。
总结一下，SPL之所以更简单是因为SPL相当于结合了SQL和其他高级语言（如Java）的优点，并在此基础上增加了诸多特性让复杂计算不再难写，同时可以与应用完美结合使得应用架构更为合理。有了SPL的帮助，我们相信，未来的某一天上千行的复杂SQL将不复存在。
SPL资料
  • SPL下载
  • SPL源代码