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

发布时间:2017-08-21 分类:数据蒋堂 Tag:,,,

sjjt-20

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

离散性是个很简单的特性,几乎所有支持结构(对象)的高级语言都天然支持,比如我们用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的优点。

更多《数据蒋堂》文章