【数据蒋堂】第19期：从SQL语法看集合化

SQL作为最常用的结构化数据计算语言，虽然在做一些细致处理时不太方便，但用于描述基本运算还是比Java等高级语言要简单许多。这是因为SQL是一种集合化的语言，而Java等语言不是。我们下面从SQL的语法上看集合化语言的一些特征，为了方便讨论，我们就用Java作为参照语言，其它高级语言是类似的。

集合运算能力

结构化数据经常是批量（以集合形式）出现的，为了方便地计算这类数据，程序设计语言有必要提供足够的集合运算能力。

Java等高级语言则没有直接提供集合运算类库，虽然也有数组（相当于集合）数据类型，但并没有定义多少基本运算，以至于我们要对数据成员做个简单地求和也需要写四五行循环语句才能完成，而要做过滤、分组聚合等运算则常常要写出数百行代码。代码过长不仅仅是写起来很繁琐，而且也不利于理解算法的整体结构，算法过程都湮没在细节处理中。

而SQL则提供有较丰富的集合运算，如SUM/COUNT等聚合运算，WHERE用于过滤、GROUP用于分组，也支持针对集合的交、并、差等基本运算。这样写出来的代码就会短小很多。

表达式参数

那么，有了集合运算能力是否就够了呢？假如，我们为Java这类语言开发一批的集合运算类库，是否就可以达到SQL的效果呢？

没有这么简单！

我们来看一下过滤运算。过滤通常需要一个条件，把满足条件的集合成员保留，更技术的说法，是保留条件计算结果为真的成员。在SQL中这个条件是以一个表达式形式出现的，比如写WHERE x>0，就表示保留那些使得x>0计算结果为真的成员。这个表达式x>0并不是在执行这个语句之前先计算好的，而是在针对集合成员遍历时才计算的。本质上，这个表达式就是一个函数，是一个以当前集合成员为参数的函数。对于WHERE运算而言，相当于把一个用表达式定义的函数用作了WHERE的参数。

Java的语法不能直接支持这种写法。Java当然也允许把一个函数作为参数传递给另一个函数，但写法要麻烦很多，需要事先定义一个函数，代码看起来非常臃肿。而直接把表达式写到函数的参数中，会被先计算出来，而不是针对每个集合成员分别计算。

相比之下，SQL这种用表达式直接定义函数而作为参数传递的方法，显然要简捷和直观得多了。

这种写法有一个术语叫做lambda语法，或者叫函数式语言。

SQL中大量使用了lambda语法。除了过滤这种运算可以说必须要用外，有些并非必须的情况，使用了这种语法形式也会更为简单。比如聚合函数中可以填入表达式来计算运算后的聚合值，如sum(x*x)计算平方和，这里x*x也是在sum的执行过程中再计算的。在不支持lamdba语法时，我们也可以先用集合运算计算出成员平方构成的集合，再针对这个集合进行地求和，但写法上就不如使用lamdba语法更为直观，毕竟针对单个成员的表达式要比针对整个集合的计算更容易书写和理解。

直接引用字段

结构化数据并非简单的单值，而是带有字段的记录。

我们看到，在SQL的表达式参数中引用记录字段时，大多数情况可以直接使用字段名称而不必指明字段所属的记录，只有在多个同名字段时才需要冠以表名（或表的别名）以示区分。

再来看Java，即使我们可以容忍事先定义函数来变相实现lambda语法，也只能把当前记录作为参数传入这个函数，然后再写计算式时就总要带上这个记录。比如用单价和数量计算金额时，如果用于表示当前成员的参数名为x，则需要写成 “x.单价*x.数量”。而在SQL中可以更为直观地写成 "单价*数量”。

SQL中这些看起来理所当然的语法风格，其实背后并没有那么简单，这需要精心设计后才能被解释程序正确解析和运算。某些支持lambda语法的脚本语言就没有这个特性，虽然可以用表达式定义函数作为参数传递，但必须写成“x.单价*x.数量”这种啰嗦的形式。有了直接引用字段的语法机制后，才可以说是专门面向结构化数据计算的语言。

动态数据结构

SQL还能很好地支持动态数据结构。

结构化数据计算中，返回值经常也是有结构的数据，而结果数据结构和运算相关，没办法在代码编写之前就先准备好。所以需要支持动态的数据结构能力。

SQL中任何一个SELECT语句都会产生一个新的数据结构，在代码中可以随意添加删除字段，而不必事先定义结构（类）。Java这类语言则不行，在代码编译阶段就要把用到的结构（类）都定义好，原则上不能在执行过程中动态产生新的结构。

解释型语言

动态数据结构不能在编译型语言中实现。前面说到的lambda语法也不适合采用编译型语言来实现。编译器不能确定这个写到参数位置的表达式是应该当场计算出表达式的值再传递，还是把整个表达式编译成一个函数传递，需要再设计更多的语法符号加以区分。而解释型语言则没有这个问题，作为参数的表达式是先计算还是遍历集合成员时再计算，可以由函数本身来决定。解释执行是集合化语言的另一个重要特征。