数据蒋堂 | 常规遍历语法

2017 年 9 月 13 日 数据派THU

来源：数据蒋堂

作者：蒋步星

本文长度为1752字，建议阅读4分钟

本文为你介绍遍历运算中的可能情况，并讨论SQL语法在这方面的表现。

遍历可以说是最基本的集合运算了，比如求和、计数、寻找最大最小值等聚合运算，按条件过滤集合、根据集合成员生成另一个新集合，也都是遍历运算。集合化语法要求我们能用很短的语句（经常就只有一句，而不是若干语句构成的一段程序）来描述大部分遍历运算，这样我们需要考查遍历运算中可能出现的各种常见情况，并设计出合理自治的语法规则。

我们从简单到复杂来考查遍历运算中的可能情况，并讨论SQL语法在这方面的表现。

1. 直接针对集合成员运算

比如计算集合成员的合计。

这是最简单的情况，采用普通的函数语法风格就可以，将待遍历的集合作为参数获得返回值，比如sum(A)用于计算集成A成员的合计，当然也可以使用对象式的语法风格写成A.sum()。

2. 引用集合成员

比如我们不是要计算集合成员的合计，而是要计算平方和，那么这个平方该如何描述？

这就会用到我们在谈集合化语法时提到的lambda语法。平方这个运算本质上是一个函数，在遍历过程中它以被遍历集合的当前成员作为参数，返回该参数的平方。而lambda语法允许将这个函数以表达式的形式并一起写入整个计算遍历运算式，一个语句就可以完成。但这里就有一个问题，我们在这个lambda表达式中用什么标识符或符号表示这个当前成员呢？

显然，像普通函数那个先定义参数名不是个好办法，那会让lamdba表达式写得很臃肿，失去lambda语法的简洁性。尽管有些程序设计语言确实是这么做的，不过我们并不提倡。使用一个固定的标识符也不好，太长了用起来不方便，太短又很可能与其它局部变量重名导致歧义。我们提倡在这里使用一个特殊符号来完成这个目的。

比如使用~表示当前成员时，平方和就可以写成A.sum(~*~)，简单易懂。也可以分两步做，先计算出集合成员的平方构成一个新集合，再计算新集合的合计，写成类似A.(~*~).sum()的形式，后一步不再需要~写法，前一步仍需要~写法来描述平方这个表达式函数。

3. 使用结构化数据时引用字段

但是，我们发现，被认为是集合化语言的SQL中并没有使用某个符号或标识符来表示当前遍历成员，那么SQL又是怎么解决上一部分的第二个问题的呢？

事实上，SQL并没有普通意义上可由任何成员构成的集合。SQL的集合就是表，而表的成员都是相同结构的记录。SQL体系中有记录这个概念，但并不能把记录作为一种数据类型来引用。如果我们要在SQL中针对一个单值成员的集合进行遍历，也只能把单值做成只有一个字段的记录，而针对这些记录构成的表进行遍历。所有计算都是针对某些字段进行的，而不能针对整条记录。

但这和SQL没有表示当前成员的符号有什么关系呢？

我们在前面说集合化语法时还提到，面向结构化数据计算的集合化语法需要有简洁的方式引用字段，SQL提供了可以直接引用字段的便捷机制，而SQL又只能计算字段，那就可以不必再提供引用当前成员（记录）的手段了。比如SQL中计算平方和一定是某个字段的平方和，而整条记录（集合成员）的平方则没有意义。

SQL牺牲了集合的表达能力而简化了语法。对于能够支持泛型成员构成集合的语言来讲，~写法就是必要的了。而且，如果用于结构化数据计算时，SQL这种可以直接字段的写法也要得到支持才会方便，计算某销售帐目的金额时写成"~.单价*~.数量"显然不如写成"单价*数量“更为简单直观，好的程序语言应当借鉴SQL这种风格。

4. 嵌套引用时的规则

遍历在本质上就是一个循环，而循环语句可能有多层，这样遍历也可能会有嵌套引用。比如计算A,B两个集合的交集，简单的算法就是遍历A的成员，看是不是在B集合中出现过（也是遍历），这就会涉及到两层的遍历。

这时候~写法就会产生歧义了，~到底是指A集合还是B集合的当前成员，这需要在语法规则上做一个明确的约定。

一般采用的是就近原则，即如果没有指明~是哪个集合的，那缺省认为是内层遍历集合的，而外层遍历集合的当前成员则需要显式地指出其从属于哪个集合。计算交集的表达式就可以写成A.select(B.count(~==A.~)>0)，其中的~缺省表示B的当前成员，而另一个要显式地写成A.~以示区分。

面向结构化数据计算时可以直接引用字段名，这时也可能产生内外层的歧义，也可以适用于就近原则，SQL就是这样。当内外层表有相同字段名时，则缺省被认为是内存表的字段，引用外层表的同名字段时必须显式地写上表名；如果内外存表中没有相同字段名，则可以正确识别出来而不必书写表名。

遍历运算虽然很基本，但设计其语法时仍有一些注意事项。SQL在这方面总体表现不错，除了缺乏泛型成员的集合外，用于描述常规遍历运算还是比较方便简捷的。

专栏作者简介

润乾软件创始人、首席科学家

清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。

数据蒋堂

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

往期回顾：

数据蒋堂 | 从SQL语法看离散性

数据蒋堂 | 从SQL语法看集合化

数据蒋堂 | SQL用作大数据计算语法好吗？

数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

数据蒋堂 | 非结构化数据分析是忽悠？

数据蒋堂 | 多维分析的后台性能优化手段

编辑：王璇

校对：叶龚兵

为保证发文质量、树立口碑，数据派现设立“错别字基金”，鼓励读者积极纠错。

若您在阅读文章过程中发现任何错误，请在文末留言，或到后台反馈，经小编确认后，数据派将向检举读者发8.8元红包。

同一位读者指出同一篇文章多处错误，奖金不变。不同读者指出同一处错误，奖励第一位读者。

感谢一直以来您的关注和支持，希望您能够监督数据派产出更加高质的内容。