【数据蒋堂】第20期：从SQL语法看离散性

所谓离散性，是指集合的成员可以游离在集合之外存在并参与运算，游离成员还可以再组成新的集合。从离散性的解释上可以知道，离散性是针对集合而言的一种能力，离开集合概念单独谈离散性就没有意义了。

离散性是个很简单的特性，几乎所有支持结构（对象）的高级语言都天然支持，比如我们用Java时都可以把数组成员取出来单独计算，也可以再次组成新的数组进行集合运算（不过Java几乎没有提供集合运算类库）。

但是SQL的离散性却很差。

SQL体系中有记录的概念，但并没有显式的记录数据类型。单条记录被SQL作为只有一条记录的临时表处理，也就是个单成员的集合。而且，SQL从表（集合）中取出记录时总是复制出一条新记录，和原表中的记录已经没有关系了，这个特性被称为immutable。immutable特性有助于保证代码的正确性和简单性，但也会丧失离散性。

缺失离散性会带来代码的繁琐和效率的低下。

比如要计算张三和李四的年龄差和工资差，SQL要写成两句：

SELECT (SELECT age FROM employee WHERE name='张三') - ( SELECT age FROM employee WHERE name='李四') FROM dual
SELECT (SELECT salary FROM employee WHERE name='张三') - ( SELECT salary FROM employee WHERE name='李四') FROM dual

这不仅书写麻烦，而且要重复查询。

如果支持较好的离散性，我们可以写成这样：

a = employee.select@1(name="张三")
b = employee.select@1(name="李四")
agediff=a.age-b.age
salarydiff=a.salary-b.salary

查询结果可以游离在集合外独立存在，并可以反复使用。

immutable特性会要求每次运算都复制数据，这在只读的运算中还只是浪费时间和空间影响效率，但如果要改写数据时，造成的麻烦就严重得多。

比如我们想对业绩在前10%销售员再给予5%的奖励。一个正常思路是先把业绩在前10%的销售员找出来，形成一个中间集合，然后再针对这个集合的成员执行奖励5%的动作。但由于SQL缺乏离散性，immutable特性导致满足条件的记录再形成的集合和原记录是无关的，在中间结果集上做修改没有意义。这样就迫使我们要把整个动作写成一个语句，直接在原表中找到满足条件的记录再加以修改，而前10%这种条件并不容易简单地在WHERE子句中写出来，这又会导致复杂的子查询。这还只是个简单例子，现实应用中比这复杂的条件比比皆是，用子查询也很难写出，经常采用的办法则是先把满足条件的记录的主键计算出来，再用这些主键到原表中遍历找到原记录去修改，代码繁琐且效率极为低下。

如果语言支持离散性，我们就可以执行上述思路了：

a=sales.sort@z(amount).to(sales.len()*0.1)   //取出前业绩在10%的记录构成一个新集合
a.run(amount=amount*1.05)       //针对集合成员执行奖励5%动作

从上面两个简单例子可以看出，缺失离散性会加剧分步计算的困难，immutable特性会降低性能并占用空间。当然，离散性的问题还不止于此。

不能用原集合的成员构成新集合再进行计算，SQL在做分组时无法保持分组子集，必须强迫聚合，作为集合化语言，SQL的集合化并不彻底。没有游离记录及其集合的表示方法，只能用传统的外键方案表示数据之间的关联关系，写出的代码即繁琐又难懂，而且运算性能还差，缺乏离散性的SQL无法采用直观的引用机制描述关联。特别地，没有离散性的支持，SQL很难描述有序计算，有序计算是离散性和集合化的典型结合产物，成员的次序在集合中才有意义，这要求集合化，有序计算时又要将每个成员与相邻成员区分开，会强调离散性。

这些具体内容我们会在后续文档中逐步详细说明。我们要从理论上改进SQL（或者更合适的说法是关系代数），主要工作就是在保持集合化的基础上引入离散性，从而解决上述问题，让新的语言能够同时拥有SQL和Java的优点。