分组是数据库中的常见运算，但未必所有人都能深刻地理解它。
分组运算的实质是将一个集合按照某种规则拆分成若干个子集，也就是说，返回值应当是一个由集合构成的集合，但人们一般并不太关心构成这个集合的成员集合（也就是分组子集），而是对这些子集的聚合值更感兴趣，因此，分组运算常常伴随着对子集的进一步汇总计算。
SQL 就是这么设计的，有 GROUP BY 子句时，SELECT 部分除了分组字段外，就只能写入聚合运算表达式了。当然还有个原因是 SQL 的离散性问题，无法返回集合的集合，也只能强迫实施聚合运算了。
久而久之，人们会认为分组总是需要配合后续的聚合运算，而忘记了分组和聚合其实是两个独立的步骤。

但是，我们仍然有对这些分组子集而不是聚合值更感兴趣的时候。
比如，我们想找出公司里有哪些员工和其他员工会在同一天过生日，很简单的思路是将员工按生日分组，然后找出成员数大于 1 的分组子集，再做个并集。这时候我们就不是只对聚合值（分组子集的成员数）感兴趣，而是对分组子集本身更感兴趣。
这个运算用 SQL 写起来就会比较啰嗦，需要用子查询，并且要遍历两次原集合。

SELECT * FROM employee WHERE birthday IN
    ( SELECT birthday FROM employee GROUP BY birthday HAVING COUNT(*)>1 )

歪个楼说句题外话：这里假定 birthday 字段就是生日，其实我们日常意义的生日是没有年份的，而数据表中的 birthday 字段通常会有，这时候还需要把 birthday 转换成月和日再做 GROUP 和 WHERE，但由于 SQL 的集合化不彻底，涉及两个成员的 IN 运算很难写，这个 birthday 要改写类似 month(birthday())*100+day(birthday) 的样子，拼成一个单独的表达式才能使用 IN 来判断，非常繁琐。

拥有离散性的 SPL 有更彻底的集合化特性，能提供集合的集合这种数据类型，也就可以保持住分组子集。这样，分组和聚合还原成两个步骤，上面的运算就可以很清晰地写出来：

employee.group(month(birthday),day(birthday)).select(~.len()>1).conj()

按 birthday 的月 / 日分组，过滤出成员数大于 1 的分组子集，然后求并集。分组针对多个键是很自然的事，也不用再拼成单独表达式再使用 IN 了。
事实上这个语句仍然要再二次遍历数据，但只是计数，不需要象 SQL 那样做比较，性能要好很多。

退一步讲，就算我们只对聚合值感兴趣，我们也可能需要保持住这些分组子集以便反复利用，计算出多种聚合值，而不是完成一次聚合后就将其丢弃，下次再计算时又要重新分组。分组是个成本不低的运算，现在一般使用 HASH 方法实现分组，计算和比较 HASH 值都要比简单遍历复杂很多。
比如我们计算每个部门的人数，再计算出 10 人以上部门的人员平均年龄。这在 SQL 中就要写成两句，因为后者需要一个 HAVING 条件：

SELECT department,COUNT(*) FROM employee GROUP BY department
SELECT department,AVERAGE(age) FROM employee GROUP BY department HAVING COUNT(*)>=10

这里 GROUP 动作就要被执行两遍。
而如果能够保持分组子集，则只要做一次 group 就可以了，SPL 中就不必重复分组：

g=employee.group(department)
g.new(~.department,~.len())
g.select(~.len()>=10).new(~.department,~.avg(age))

还有的可能是，我们确实只对某个聚合值感兴趣，但这个聚合值很难计算，并不能简单地用 SUM/COUNT 计算出来的，需要编段程序才行，这时候也需要保留分组子集，而用 SQL 就很难实现这种运算了。我们会在后续讲到聚合运算时再涉及。

分组的结果是集合的集合，它仍然是个集合，那显然还可以进一步分组。

g1=employee.group(year(birthday))		//按出生年份分组
g2=g1.group(year(birthday)%100\10)		//将所有分组子集按年代分组
g3=g1.(~.group(month(birthday)))		//将每个分组子集按出生月份分组

后两步运算都会得到集合的集合的集合，三层或更深的情况在现实业务中很少碰到，但可以用来体会集合的思维方式以及分组运算的本质。

再说句相关的话。SQL 针对 GROUP 后的结果集过滤专门设计了 HAVING 关键字，许多初学者对 HAVING 的理解和运用有点困惑。其实，HAVING 从概念上讲是多余的，它和 WHERE 并没有任何差别，只是因为 SQL 无法保持分组子集，要把分组和聚合写在一句话中，又要和 WHERE 区分，然后硬造出来的一个关键字。如果能够保持分组子集后实现分步计算，HAVING 是没有必要的。SPL 里就没有也不需要这个东西。