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

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