【数据蒋堂】第19期:从SQL语法看集合化

SQL作为最常用的结构化数据计算语言,虽然在做一些细致处理时不太方便,但用于描述基本运算还是比Java等高级语言要简单许多。这是因为SQL是一种集合化的语言,而Java等语言不是。我们下面从SQL的语法上看集合化语言的一些特征,为了方便讨论,我们就用Java作为参照语言,其它高级语言是类似的。

集合运算能力

结构化数据经常是批量(以集合形式)出现的,为了方便地计算这类数据,程序设计语言有必要提供足够的集合运算能力。

Java等高级语言则没有直接提供集合运算类库,虽然也有数组(相当于集合)数据类型,但并没有定义多少基本运算,以至于我们要对数据成员做个简单地求和也需要写四五行循环语句才能完成,而要做过滤、分组聚合等运算则常常要写出数百行代码。代码过长不仅仅是写起来很繁琐,而且也不利于理解算法的整体结构,算法过程都湮没在细节处理中。

而SQL则提供有较丰富的集合运算,如SUM/COUNT等聚合运算,WHERE用于过滤、GROUP用于分组,也支持针对集合的交、并、差等基本运算。这样写出来的代码就会短小很多。

表达式参数

那么,有了集合运算能力是否就够了呢?假如,我们为Java这类语言开发一批的集合运算类库,是否就可以达到SQL的效果呢?

没有这么简单!

我们来看一下过滤运算。过滤通常需要一个条件,把满足条件的集合成员保留,更技术的说法,是保留条件计算结果为真的成员。在SQL中这个条件是以一个表达式形式出现的,比如写WHERE x>0,就表示保留那些使得x>0计算结果为真的成员。这个表达式x>0并不是在执行这个语句之前先计算好的,而是在针对集合成员遍历时才计算的。本质上,这个表达式就是一个函数,是一个以当前集合成员为参数的函数。对于WHERE运算而言,相当于把一个用表达式定义的函数用作了WHERE的参数。

Java的语法不能直接支持这种写法。Java当然也允许把一个函数作为参数传递给另一个函数,但写法要麻烦很多,需要事先定义一个函数,代码看起来非常臃肿。而直接把表达式写到函数的参数中,会被先计算出来,而不是针对每个集合成员分别计算。

相比之下,SQL这种用表达式直接定义函数而作为参数传递的方法,显然要简捷和直观得多了。

这种写法有一个术语叫做lambda语法,或者叫函数式语言。

SQL中大量使用了lambda语法。除了过滤这种运算可以说必须要用外,有些并非必须的情况,使用了这种语法形式也会更为简单。比如聚合函数中可以填入表达式来计算运算后的聚合值,如sum(x*x)计算平方和,这里x*x也是在sum的执行过程中再计算的。在不支持lamdba语法时,我们也可以先用集合运算计算出成员平方构成的集合,再针对这个集合进行地求和,但写法上就不如使用lamdba语法更为直观,毕竟针对单个成员的表达式要比针对整个集合的计算更容易书写和理解。

直接引用字段

结构化数据并非简单的单值,而是带有字段的记录。

我们看到,在SQL的表达式参数中引用记录字段时,大多数情况可以直接使用字段名称而不必指明字段所属的记录,只有在多个同名字段时才需要冠以表名(或表的别名)以示区分。

再来看Java,即使我们可以容忍事先定义函数来变相实现lambda语法,也只能把当前记录作为参数传入这个函数,然后再写计算式时就总要带上这个记录。比如用单价和数量计算金额时,如果用于表示当前成员的参数名为x,则需要写成 “x.单价*x.数量”。而在SQL中可以更为直观地写成 "单价*数量”。

SQL中这些看起来理所当然的语法风格,其实背后并没有那么简单,这需要精心设计后才能被解释程序正确解析和运算。某些支持lambda语法的脚本语言就没有这个特性,虽然可以用表达式定义函数作为参数传递,但必须写成“x.单价*x.数量”这种啰嗦的形式。有了直接引用字段的语法机制后,才可以说是专门面向结构化数据计算的语言。

动态数据结构

SQL还能很好地支持动态数据结构。

结构化数据计算中,返回值经常也是有结构的数据,而结果数据结构和运算相关,没办法在代码编写之前就先准备好。所以需要支持动态的数据结构能力。

SQL中任何一个SELECT语句都会产生一个新的数据结构,在代码中可以随意添加删除字段,而不必事先定义结构(类)。Java这类语言则不行,在代码编译阶段就要把用到的结构(类)都定义好,原则上不能在执行过程中动态产生新的结构。

解释型语言

动态数据结构不能在编译型语言中实现。前面说到的lambda语法也不适合采用编译型语言来实现。编译器不能确定这个写到参数位置的表达式是应该当场计算出表达式的值再传递,还是把整个表达式编译成一个函数传递,需要再设计更多的语法符号加以区分。而解释型语言则没有这个问题,作为参数的表达式是先计算还是遍历集合成员时再计算,可以由函数本身来决定。解释执行是集合化语言的另一个重要特征。

原文发布时间为:2017-8-15

本文作者:蒋步星

本文来自合作伙伴“数据蒋堂”,了解相关信息可以关注“数据蒋堂”微信公众号

时间: 2024-11-01 08:31:39

【数据蒋堂】第19期:从SQL语法看集合化的相关文章

【数据蒋堂】第20期:从SQL语法看离散性

所谓离散性,是指集合的成员可以游离在集合之外存在并参与运算,游离成员还可以再组成新的集合.从离散性的解释上可以知道,离散性是针对集合而言的一种能力,离开集合概念单独谈离散性就没有意义了. 离散性是个很简单的特性,几乎所有支持结构(对象)的高级语言都天然支持,比如我们用Java时都可以把数组成员取出来单独计算,也可以再次组成新的数组进行集合运算(不过Java几乎没有提供集合运算类库). 但是SQL的离散性却很差. SQL体系中有记录的概念,但并没有显式的记录数据类型.单条记录被SQL作为只有一条记

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

所谓离散性,是指集合的成员可以游离在集合之外存在并参与运算,游离成员还可以再组成新的集合.从离散性的解释上可以知道,离散性是针对集合而言的一种能力,离开集合概念单独谈离散性就没有意义了. 离散性是个很简单的特性,几乎所有支持结构(对象)的高级语言都天然支持,比如我们用Java时都可以把数组成员取出来单独计算,也可以再次组成新的数组进行集合运算(不过Java几乎没有提供集合运算类库). 但是SQL的离散性却很差. SQL体系中有记录的概念,但并没有显式的记录数据类型.单条记录被SQL作为只有一条记

【数据蒋堂】第18期:SQL用作大数据计算语法好吗?

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流.兼容SQL的好处是很明显的,SQL的应用非常广泛,会SQL的程序员很多,如果继续采用SQL则可以避免许多学习成本.支持SQL的前端软件也很多,使用SQL的大数据平台很容易融入这个现成的生态圈中.大数据平台打算替代的传统数据库也是SQL语法的,这样兼容性会很好,移植成本相对较低. 但继续使用SQL也有缺点,最大的问题就是难以获得大数据计算最需要的高性能. 我们在前面的文章中提到过,SQL中缺乏一些必要的数据类型和运算定义,这使得某些

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

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流.兼容SQL的好处是很明显的,SQL的应用非常广泛,会SQL的程序员很多,如果继续采用SQL则可以避免许多学习成本.支持SQL的前端软件也很多,使用SQL的大数据平台很容易融入这个现成的生态圈中.大数据平台打算替代的传统数据库也是SQL语法的,这样兼容性会很好,移植成本相对较低. 但继续使用SQL也有缺点,最大的问题就是难以获得大数据计算最需要的高性能. 我们在前面的文章中提到过,SQL中缺乏一些必要的数据类型和运算定义,这使得某些

【数据蒋堂】第17期:SQL的困难源于关系代数

在结构化数据处理领域,SQL无疑是应用最广泛的工作语言,不仅被所有关系数据库采用,许多新进的大数据平台也将实现SQL作为目标.但现实是,面对当前纷杂的计算查询需求,SQL在很多方面并不够好用.我们在前面说过SQL的过程性问题,这其实并不是最关键的问题,SQL的更大困难来源于其理论基础,即关系代数. 关系代数是一种代数体系.我们无法在本文的篇幅中严格定义代数体系这个概念,只能通俗地解释.人们为解决某种运算问题,定义了一些数据对象及针对这些数据对象的一套运算规则,确保这些运算的封闭性和自洽性,就可以

【数据蒋堂】第28期:迭代聚合语法

我们讨论过的常规聚合运算如SUM/COUNT和非常规聚合运算如maxp/top,都是事先设计好的聚合函数.但如果我们想实现一个以前没有定义过的运算怎么办?是否可以用已有的语法和函数组合出来?比如想做连乘运算,显然这也算是一种聚合. 要设计这样的语法方案,我们来看看这些聚合结果值是如何被程序计算出来的. SUM:先设置一个初始值0,然后遍历集合的每个成员,每次将成员值加到初始值上,直到成员被遍历完.COUNT:设置初始值0,遍历集合成员,每次碰到非空成员将初始值加1,直到遍历完.AVERAGE:这

【数据蒋堂】第21期:常规遍历语法

遍历可以说是最基本的集合运算了,比如求和.计数.寻找最大最小值等聚合运算,按条件过滤集合.根据集合成员生成另一个新集合,也都是遍历运算.集合化语法要求我们能用很短的语句(经常就只有一句,而不是若干语句构成的一段程序)来描述大部分遍历运算,这样我们需要考查遍历运算中可能出现的各种常见情况,并设计出合理自洽的语法规则. 我们从简单到复杂来考查遍历运算中的可能情况,并讨论SQL语法在这方面的表现. 1. 直接针对集合成员运算 比如计算集合成员的合计. 这是最简单的情况,采用普通的函数语法风格就可以,将

【数据蒋堂】第16期:SQL像英语是个善意的错误

我们知道,SQL长得很像英语,简单的SQL语句直接可以作为英语读.除了SQL外,其它主要程序设计语言都没有这样,语法中就算有英语单词也仅仅是作为某些概念或操作的助记符而已,写出来的是形式化的程序语句(statement)而不是英语句子(sentence).而SQL不同,它会把整个句子写成符合英语习惯的形式,还会补充很多不必要的介词,比如FROM作为语句的运算主体却被写到后面,GROUP后面要写一个多余的BY. 为什么会这样?很容易想到的理由是希望非程序设计人员也能使用.用户只要会读写英语,就可以

【数据蒋堂】第3期:功夫都在报表外-漫谈报表性能优化

应用系统中的报表,作为面向业务用户的窗口,其性能一直被高度关注.用户输入参数后都希望立即就能看到统计查询结果,等个十几二十秒还能接受,等到三五分钟的用户体验就非常恶劣了. 那么,报表为什么会慢,又应当从哪里入手进行性能调优呢? 数据准备 当前应用中的报表大都用报表工具开发,当报表响应太慢时,不明就里的用户就会把矛头指向使用报表工具的开发人员或者报表工具厂商.其实,大多数情况报表的慢只是个表现,背后的原因是数据准备太慢,在数据进入报表环节之前就已经慢了,这时再去优化报表开发或压迫报表工具并没有用处