细心的读者可能会发现，我们在讨论有序分组时只研究了待分组集合的成员次序对分组运算可能的影响，但即然要考虑集合的有序性，那么结果集的成员次序是不是也有业务意义呢?
确实有意义，不过重要程度不如原集有序性。
一
分组结果集的有序性有两个方面，一是这些分组子集以什么次序返回，二是分组子集的成员是什么次序构成的。
在考虑有序集合的等值分组运算时，我们认为在缺省状态下分组子集保持原序最为合理，即每个分组子集成员***次在原集中出现的次序。这个原因在于：其它次序(比如按分组字段值)可以针对结果集再排序而获得，而原序很可能在分组完成后就丢失了，或者至少再获得会比较困难。
比如我们要统计一本教科书中单词的重复次数，这是个简单的等值分组运算，缺省的结果集应当是以新单词在书中出现的先后次序为序的，这个次序是有业务意义的，向学生讲授这本书时可以按该次序让学生预习生词。而这个次序如果不是在分组运算后返回，就会很难获得了。需要给每个单词人为增加一个在书中出现的次序号，分组时同时把次序号的最小值也统计出来，然后再按这个值排序，***又丢弃这个值。运算过程繁琐且效率低。
对位分组和枚举分组的结果集次序，显然应当与基准集合一致。而有序分组的结果集次序，则显然按每个分组产生的次序最为合理。
二
基于无序集合的SQL没有约定分组结果集的次序，返回结果集就不能保证原序了。在实践上，数据库一般是采用HASH方法来实现分组的，这时结果集的次序常常是HASH值的次序，而HASH值次序毫无业务意义，在关心次序时就还需要再排序，而为了获得排序依据就要象前面例子中说的那样在原集中新增序号信息，并参与到分组运算中，麻烦且低效。还有的数据库是用排序来做分组，结果集的次序就是分组字段(表达式)的次序，这个次序有一定业务意义了，但想还原出原序也不容易。
我们前面说过，SQL中用LEFT JOIN的方法可以实现出对位和枚举分组的效果，但无论是HASH方法还是排序方法，结果集都会丧失基准集合的次序。而对位和枚举分组的结果集次序又是非常必要的，想通过再排序来获得这个次序，需要在基准集合中就要维护个次序号，这会使得本来简单的单值成员集合变成多字段的记录集合，而且当基准集合需要插入/删除成员时还要继续维护序号会是个很麻烦的事情，被改动成员后面的成员序号都要调整。所以SQL实现对位和枚举分组是个很繁琐的事情。
三
至于子集成员的次序，原则上也应当缺省保持原序，也就是在原集合中的次序。不过，它是否有意义取决于后续要执行的动作。
比如SQL就完全不关心这个次序，SQL在分组后会强制聚合，而且只有SUMM/COUNT这些运算结果与执行次序无关的常规聚合运算，分组子集的成员次序就没有意义了。
但有些非常规聚合运算可能和执行次序有关，比如用登录日志(日志缺省都是按事件发生时刻有序的)列出每个用户的***两次登录的时间间隔，就是按用户分组后取出分组子集的***两条记录计算时间差，这时就会关心子集成员的次序了。不过，这已经是聚合运算的范畴了，我们将在后面的文章中再详细讨论。
