专栏名称: 数据派THU
本订阅号是“THU数据派”的姊妹账号,致力于传播大数据价值、培养数据思维。
目录
相关文章推荐
数据派THU  ·  【NUS博士论文】视频语义理解中的因果模型 ·  2 天前  
数据派THU  ·  LLM4Rec最新重磅工作:字节跳动序列推荐 ... ·  2 天前  
软件定义世界(SDX)  ·  中小企业数字化体系设计 ·  4 天前  
软件定义世界(SDX)  ·  ERP 是信息化还是数字化(万字长文) ·  1 周前  
51好读  ›  专栏  ›  数据派THU

数据蒋堂 | SQL像英语是个善意的错误

数据派THU  · 公众号  · 大数据  · 2017-07-28 19:00

正文

来源:数据蒋堂

作者:蒋步星

本文长度为1580,建议阅读4分钟

本文为你解析为何SQL长得像英语词语。

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

为什么会这样?很容易想到的理由是希望非程序设计人员也能使用。用户只要会读写英语,就可以写出SQL来查询数据。这显然是个善意的初衷,但结果却不尽如人意。绝大多数业务人员只会用SQL写非常简单的查询,而对于这类查询,应用程序常常都有更为便捷直观的可视化界面来协助,并不需要直接手写语句,这个设计初衷就失去意义。反过来, 经常使用SQL做运算的仍然是程序员,SQL还是一种编程语言,像不像英语对于程序员理解并没有多大差别,反而会带来不小的困难。

事实上,SQL是一种语法非常严格的语言,语句中任何一点不合规的地方就会被解释器拒绝,使用者必须认真学习并遵守其语法规则,这和其它程序设计语言并没什么两样。而自然语言真正的优势在于具有模糊性,可以一定程度接受不严格的语法,但SQL并没有支持这一点,在发明SQL那个年代也实现不了这个特性。

像英语的好处没有体现,坏处却很严重,将语法设计得像自然语言,看起来容易掌握,其实恰恰相反。

贴近自然语言带来的主要坏处是非过程性。程序逻辑一般是分步执行的,用变量记录中间结果,供后面的步骤使用。但自然语言不是这样,两句话之间的引用关系靠少量几个代词维系,不够用且不精确,所以更习惯的做法是把尽量多的任务写在一句话中,复杂情况下就会大量使用从句。在SQL中的表现就是一句话中配有多个动作,SELECT、WHERE、GROUP都拼进去,像WHERE和HAVING其实是一个意思,却要采用两个词以示区别,而查询需求复杂时就会出现多层嵌套的子查询。这种现象在其它程序设计语中是不常见的。

分步是降低理解和执行难度的有效法门,本来挺简单分几步能做到的事情,如果不分步就会很绕。比如要找出销售额超过平均值两倍的客户,自然思维方式就是先算出销售额的平均值,再找出销售额超这个值两倍的客户,两个语句完成。而SQL的写法就需要用子查询写成更长的一句。这个例子还算好懂,只有两层,一般自然语言的从句用来描述两层关系的理解难度还可以接受,但实际复杂的查询涉及到三五层的比比皆是,严重增加理解难度。

不提倡分步,就会导致单句SQL很长。程序员面临的复杂SQL语句,很少以行计,经常是以K计。而同样的100行代码,分成100个语句还是只有1个语句,其复杂度完全不是一个层面的。这种代码理解起来非常困难,好不容易写出来,过两个月后自己都读不懂,而且太长不分步的单句非常难以调试,开发周期也更长。

关于过程性,SQL的拥趸者一直有一个说法:写SQL时用户只要关心要什么,而不必关心怎么做,计算机会自动找解决方案,这样语法本身不需要支持过程性。

这其实是个胡扯!

任何程序语言在某种层次上都具有这个能力,写汇编语言需要关心寄存器和内存的动作,但不必关心更下层的与非门的动作。SQL中不必关心数据在物理存储层面(文件系统、内存和硬盘)的动作,但仍然要关心逻辑层面(表和字段)的运算。SQL语句事实上也在描述运算逻辑,特别是多层嵌套关联的复杂SQL,在描述问题目标的同时,实际上也指明了执行过程,或者倒过来说,在SQL中也只能用指明执行过程的方法来描述问题目标,只不过相对比较高层次一些而已。

不过,SQL只是不提倡分步计算,而并非完全不支持过程性。使用存储过程就相当于分步执行SQL,使用外部程序调用SQL也可以实现过程性,如果不考虑临时表(用于存储中间结果)和数据库IO(外部语言调用SQL时要获得运算结果)的低性能,这些方法在功能上并没什么缺失。但要考虑到数据量导致的性能问题时,还是经常需要编写长SQL才能解决问题。在数据量较小、性能问题不突出时,可以用这些方法来补充SQL的过程性。

专栏作者简介



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


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


数据蒋堂

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


往期回顾:

数据蒋堂 | 开放的计算能力为数据库瘦身

数据蒋堂 | 计算封闭性导致臃肿的数据库

数据蒋堂 | 怎样看待存储过程的移植困难

数据蒋堂 | 存储过程的利之弊

数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 报表的数据计算层

数据蒋堂 | 报表应用的三层结构

数据蒋堂 | 列式存储的另一面

数据蒋堂 | 硬盘的性能特征

数据蒋堂 | 我们需要怎样的OLAP?

数据蒋堂 | 1T数据到底有多大?

数据蒋堂 | 索引的本质是排序

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

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

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


编辑:王璇

校对:叶龚兵

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

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

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

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

公众号底部菜单有惊喜哦!

企业,个人加入组织请查看“联合会”

往期精彩内容请查看“号内搜”

加入志愿者或联系我们请查看“关于我们”