为什么SQL的语法是由内而外的?

这个 SQL Wikipedia entry 简要介绍一些历史:

20世纪70年代,IBM圣何塞研究实验室的一个小组根据Edgar F.Codd在其影响深远的论文《大型共享数据银行的数据关系模型》中介绍的模型开发了System R关系数据库管理系统。随后,IBM的Donald D.Chamberlin和Raymond F.Boyce创建了 结构化英语查询语言(续) 为了操作和管理存储在系统R中的数据,缩写Sequel后来改为SQL,因为“Sequel”是总部位于英国的Hawker Siddeley Aircraft Company的商标。

明确提到的原名 英语 ,解释语法。

再深入一点,我们发现 FLOW-MATIC 程序设计语言。

Flow-Matic,最初称为B-0(业务语言版本0), 可能是第一种类似英语的数据处理语言 . 它由Grace Hopper发明并指定,商业变体的开发始于1955年Remington Rand为univac i开发。到1958年,编译器及其文档普遍可用,并在商业上使用。

Flow-Matic是 Common Business Oriented Language 是目前仍在使用的最古老的编程语言之一。保持这种精神, 续集 是用类似英语的句法设计的(70年代是现代的,与50年代和60年代相比)。

从长远来看,“现代”的编程系统仍然使用其背后古老的思想访问数据库。

MULTIPLY PRICE BY QUANTITY GIVING COST.

我认为,就英语句子的结构而言,SQL语句的结构方式是合乎逻辑的。基本上

I WANT THIS
FROM HERE
WHERE WHAT I WANT MEETS THESE CRITERIA

我认为至少用英语来说,这没什么意义

FROM HERE
I WANT THIS
WHERE WHAT I WANT MEETS THESE CRITERIA  

我一定不同意。SQL语法不是由内向外的。

从 第一眼看 您可以判断查询是否将选择、插入、更新或删除数据(SQL的所有其余部分,例如DDL,故意省略)。

回到您的select语句混乱:SQL的目标是 声明的 . 这意味着你表达了你想要的,而不是你想要的。所以这很有意义 第一 陈述你想要的(你的属性列表 选择 ING)和 然后 为DBMS提供一些应该从哪里查找的附加信息。

把WHERE子句放在末尾也很有意义:想象一个漏斗,顶部宽,底部窄。通过在语句的末尾添加一个WHERE子句,可以抑制生成的数据量。对查询应用除底部以外的任何地方的限制都需要开发人员改变主意。

最后的ORDERBY子句:一旦数据通过漏斗,对其进行排序。

联接(联接条件)实际上属于FROM子句。

SQL Sytax很好。这件事没有什么内幕。也许这就是为什么SQL在几十年后仍然如此流行的原因。这很容易理解和理解。(尽管我曾经遇到过一个7页(A4大小)的SQL语句,但我花了很长时间才了解它。)

它设计得像英语。我认为这是主要原因。

作为旁注,我记得Linq的初始预览是在它之后直接建模的。( select ... from ... )这在以后的预览中被更改为更像编程语言(这样范围向下)。AndersHejlsberg特别提到了关于SQL的这个奇怪的事实(这使得IntelliSense更难理解,并且与C范围规则不匹配),作为他们做出这个决定的原因。

不管怎样,好的还是坏的,这就是现状,现在改变任何事情都为时已晚。

SQL中子句的顺序是绝对合乎逻辑的。请记住,SQL是一种声明性语言,您可以在其中声明所需的内容,系统会找出如何最好地为您获得它。第一个子句是select子句,在其中列出结果表中所需的列。这是查询的主要目的。在说明了您希望结果是什么样子之后,您就可以下一步说明数据应该来自哪里。WHERE子句限制返回的数据量。除非您知道数据来自何处,否则没有必要考虑如何限制您的数据,所以它在FROM子句之后。group by子句与select子句中的聚合运算符一起工作,可以在from子句之后的任何位置执行,但是最好考虑对筛选数据进行聚合,因此它位于where子句之后。HAVING子句必须在GROUP BY子句之后。ORDERBY子句是关于如何显示数据的,并且可以在选择之后转到任何地方。

它与SQL的其余语法一致,即每个语句都以动词开头。( CREATE , DROP , UPDATE 等)。

列列表优先的主要缺点是不方便自动完成(正如Hejlsberg提到的那样),但在20世纪70年代设计语法时,这不是一个问题。

我们本可以在两个世界中使用最好的语法,比如 SELECT FROM SomeTable: ColumnA, ColumnB 但是现在改变它已经太晚了。

总之,SQL的 SELECT 语句顺序不唯一。它与python list的理解完全匹配:

[(rec.a, rec.b) for rec in data where rec.a > 0]

撇开语言的历史不谈(尽管它很吸引人),我认为您缺少的是,SQL并不是告诉系统要做什么,而是告诉系统您想要什么样的最终结果(并且它会找出如何做)

说“到那边的架子上,拿着帽子带的帽子,先是蓝帽子,然后是绿的,然后是红的,然后把它们拿给我”,这很能说明这个系统。 怎样 做你想做的。它的 程序员思考 我们认为工人非常愚蠢,需要详细的说明。

SQL首先从最终结果、所需数据、列顺序等开始。这在很大程度上是建立报告的人的观点。”我要的是名字,姓,然后是年龄,然后……”这毕竟是提出请求的目的。所以它从你想要的结果的格式开始。然后它进入到你期望它找到数据的地方,寻找什么标准,呈现它的顺序,等等。

因此,作为一种详细说明您希望工作人员做什么的替代方法,SQL假定系统知道如何做,并且更多地集中在您想要做的事情上。

所以,不要用学究式的方式告诉你的工人到这里来,拿着这个,把它拿过来。更像是说:“我想要12号架子的帽子,上面有帽带,请按颜色分类。”