我们在讨论有序分组时只研究了待分组集合的成员次序对分组运算可能的影响，但既然要考虑集合的有序性，那么结果集也是个集合，它的成员次序是不是也有业务意义呢？
确实有意义，不过重要程度不如原集的次序。

分组结果集的有序性有两个方面，一是这些分组子集的次序，二是分组子集的成员的次序。
在考虑有序集合的等值分组运算时，我们认为在缺省状态下分组子集保持原序最为合理，即每个分组子集成员第一次在原集中出现的次序。这个原因在于：其它次序（比如对分组键值有序）可以针对结果集再排序而获得，而原序很可能在分组完成后就丢失了，或者至少再获得会比较困难。
比如我们要统计一本教科书中单词的重复次数，这是个简单的等值分组运算，缺省的结果集应当是以新单词在书中出现的先后次序为序的，这个次序是有业务意义的，向学生讲授这本书时可以按该次序让学生预习生词。而这个次序如果不是在分组运算后返回，就会很难获得了。需要给每个单词人为增加一个在书中出现的次序号，分组时同时把次序号的最小值也统计出来，然后再按这个值排序，最后又丢弃这个值。运算过程繁琐且效率低。

基于无序集合的 SQL 本身也没有集合原序的说法，当然也不能约定分组结果集的次序，返回结果集保证原序就是一句无意义的命题了。在实践上，数据库一般是采用 HASH 方法来实现分组的，这时结果集的次序常常是 HASH 值的次序，而 HASH 值次序基本上毫无业务意义，在关心次序时就还需要再排序，而为了获得排序依据就要像例子中说的那样在原集合中新增序号信息，并参与到分组运算中，麻烦且低效。
刚才那个例子写出来大概会是这样：

SELECT WORD,MIN(RN) NO,COUNT(*) WC
FROM (SELECT WORD, ROWNUMBER() RN FROM T )
GROUP BY WORD ORDER BY NO

SPL 基于有序集合设计，它的分组运算会遵循这个原则，即结果集保持原序。

word.groups( ~:word; count(1):wc )

对位分组和枚举分组的结果集次序，显然应当与基准集合一致。而有序分组的结果集次序，则显然按每个分组产生的次序最为合理。
我们前面说过，SQL 中用 LEFT JOIN 的方法可以实现出对位和枚举分组的效果，但无论是 HASH 方法还是排序方法，结果集都会丧失基准集合的次序。而对位和枚举分组的结果集次序又是非常必要的，想通过再排序来获得这个次序，需要在基准集合中就要维护个次序号，这会使得本来简单的单值成员集合变成多字段的记录集合，而且当基准集合需要插入 / 删除成员时还要继续维护序号会是个很麻烦的事情，被改动成员后面的成员序号都要调整。所以 SQL 实现对位和枚举分组是个很繁琐的事情。

至于分组子集中成员的次序，原则上也应当缺省保持原序，也就是成员在原集合中的次序。不过，它是否有意义取决于后续要执行的动作。
SQL 就完全不关心这个次序，SQL 在分组后会强制聚合，而且只有 SUM/COUNT 这些运算结果与执行次序无关的常规聚合运算，分组子集的成员次序这个概念在 SQL 中就没有意义。

但有些进一步运算会和次序有关，比如按日期排序的股票收盘价表中，我们想计算每支股票最长连续上涨了多少天。这要在按股票分组后在针对每个分组子集中计算该股票最长连续上涨的天数，分组子集中成员仍然是对日期有序时，就可以比较方便地计算出来，否则还要再次排序。
SPL 对有序运算支持很好，分组结果集和分组子集成员都会遵循这些原则，保持合理的次序以方便进一步计算，像计算每支股票最长连续上涨天数就可以简单写出来：

stocks.group( stock ).new( stock, ~.group@i(price<price[-1]).max(~.len()):MaxRisingDays)