为什么说SQL看起来像英语是一个错误的设计？-Toy模板网

在数据库领域，SQL是一门具有非常严格语法的编程语言，任何不符合规范的语句部分都会被数据库拒绝。

SQL是什么?

　　虽然我们知道SQL和英语非常相似，简单的SQL语句可以直接阅读为英语，但除了SQL之外，其他主要的编程语言并没有这个特性。即使在语法中存在英语单词，也仅用作某些概念或操作的记忆方法，而实际写的是正式的程序语句，而不是英语句子。但SQL不同，它会以符合英语习惯的形式编写整个语句，并添加许多不必要的介词，例如FROM作为语句的操作主语，但必须写在后面；在GROUP之后，还需要额外写入BY。

　　为什么会出现这种情况呢？最容易想到的原因是希望非程序员也能使用它。只要用户能够阅读和书写英语，他们就可以编写SQL查询数据。这显然是一个好意图，但结果并不令人满意。绝大多数业务人员只知道如何使用SQL编写非常简单的查询，而对于这样的查询，现在有强大的BI软件可以提供更便捷直观的可视化界面来辅助，而无需手写语句。这种设计意图失去了其意义。相反，经常使用SQL进行计算的用户仍然是程序员，而SQL仍然是一种编程语言，无论是否类似于英语，对于程序员来说理解上并没有太大区别，相反，它可能带来相当大的困难。

　　事实上，SQL是一门具有非常严格语法的编程语言，任何不符合规范的语句部分都会被数据库拒绝。用户必须仔细学习和遵守其语法规则，这与其他编程语言没有太大区别。自然语言的真正优势在于其歧义性，它允许以较少严格的语法接受输入。然而，SQL并不支持这个特性，并且在SQL发明的时代也无法实现这个特性。

　　看起来像英语的优势无法体现，但有许多缺点。设计类似自然语言的语法可能看起来很容易掌握，但实际上情况恰恰相反。

　　类似自然语言的主要缺点是非过程化。程序逻辑通常是逐步执行的，使用变量记录中间结果以供后续步骤使用。但自然语言并非如此，两个句子之间的引用关系依赖于少数固定的代词，这是不准确和不方便的。因此，尽可能将针对同一主语的动作拼写到一个句子中，就无需使用代词。在SQL中的相应表示是在一个语句中有多个动作这样，例如SELECT、WHERE和GROUP，它们在最初是没有关联的动作。在其他编程语言中，它们通常被设计为多个函数，但在SQL中，它们都被设计为一个语句的子句。此外，像"WHERE"和"HAVING"这样的词语有着相同的意义，只是针对不同的对象，当拼写到一个句子中时，必须使用两个词来表示区别，这会造成困惑（许多初学者可能会对"HAVING"感到困惑）。

　　无法用单个句子描述的复杂情况可以使用自然语言中的从句来描述。这在SQL中体现为子查询，甚至可能存在多层嵌套子查询，在其他编程语言中并不常见。此外，子查询还应该像自然语言一样，每次都要使用SELECT...FROM，这会让人感觉非常啰嗦，代码会变得很长。

　　逐步操作是降低理解和执行难度的有效方法：本来只需要几个步骤就能完成的事情，如果不逐步进行，将变得非常复杂。可以想象，如果老师要求小学生只用一个方程来解决实际问题，孩子们会很苦恼（当然，有些聪明的孩子可以处理这个问题）。

　　例如，如果我们想要找出销售额超过平均值两倍的客户，自然的思维方式是首先计算平均销售额，然后找出销售额超过两倍的客户，使用两个语句来实现。而SQL的写法则要求使用子查询来写成一个更长的句子。这个例子相对容易理解，只有两层嵌套。但在实际情况中，涉及三层或五层嵌套的复杂查询非常常见，这严重增加了理解的难度。

　　不倡导逐步操作会导致单个SQL语句变得很长。程序员面临的复杂SQL语句很少按行计算，通常是以千为单位。然而，对于相同的100行代码，无论将其分成100个语句还是只有1个语句，它们的复杂性完全不同。这种类型的代码很难理解，一旦最终编写完成，两个月后，程序员自己也无法理解。此外，没有逐步操作的单个长语句很难进行调试，开发周期也更长。

　　关于过程性：行业中有一种说法，即SQL是一种声明性语言，用户只需关心他们想要什么，而不必关心如何做；数据库会自动找到解决方案，因此这种语言不需要支持过程性。我们之前已经批评了这种说法。

　　数据库供应商可能也看到了SQL的缺乏过程性，所以后来添加了CTE语法以进行补偿，它相当于提供了可以命名的中间变量。存储过程也相当于能够按步骤执行SQL，具有分支循环甚至子程序。结果仍然是回到了过程性语言的老路上，所以从一开始就设计成这样并不好。

　　对于编程语言来说，一个良好的逐步计算机制带来的易用性远远超过看起来像自然语言的优势。文章来源地址https://www.toymoban.com/diary/sql/654.html

到此这篇关于为什么说SQL看起来像英语是一个错误的设计？的文章就介绍到这了,更多相关内容可以在右上角搜索或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！