那是 1983 年，Oracle 还是一家小公司。当时，拉里·埃里森正专注于重写满是 bug 的数据库产品，而计算机教授、后来成为数据库传奇人物的 Michael Stonebraker 正在迎头追赶。

在《软件战争》（Softwar）一书中，Matthew Symonds 是这样描述这个故事的：

埃里森没有过多地关注销售，对他来说，要让 Oracle 成功，他现在能做的最重要的事情绝对是专注于改进产品。他只是觉得自己此时没有余力去关心一个 CEO 应该做的事情。对 Oracle 的一些人来说，埃里森的做法是一种开明的放权。他说：“你可以这么说，但它更像是退位，而不是放权”。

事实上，埃利森完全有理由专注在产品上。Mike Stonebraker 接手了他在加州大学伯克利分校负责的 Ingres 关系型数据库项目，并围绕该项目成立了一家名为 Relational Technology 的公司。虽然 Ingres 的商业版比 Oracle 晚进入市场，但却比 Oracle 发展得更快。1984 年，Oracle 的销售额翻了一番，达到了 1270 万美元，而名声鹊起的 Ingres 的销售额翻了三倍，达到了 900 万美元。埃利森说：“他们真的赶上来了，而且速度很快，因为我们刚刚重写了我们的数据库产品，还出现了质量问题。这些听起来是不是很熟悉？”
与 Oracle 开发 SQL 相比，Ingres 在伯克利的团队有更多的时间开发他们的语言 QUEL，而且很多关系型数据库专家认为它是一种优秀的语言。埃里森说：“也许 QUEL 比 SQL 更好，也许法语比英语更好？但这些并不重要，英语和 SQL 都将会胜出”。埃里森最担心的是 Ingres 的人才。“我意识到，我们的开发团队不够好，无法跟上 Ingres 团队的步伐，所以我们不得不重新组建我们的团队。Stonebraker 招了加州大学伯克利分校最好的学生，我们就去招加州理工学院、麻省理工学院和斯坦福大学最好的学生。我们还要招聘硅谷最有经验的编程人才。我们从 Xerox PARC 招来了一个优秀的团队。其中的一位，Derry Kabcenell，是 Oracle 公司有史以来最重要的人物之一。多亏了 Derry 和他领导的团队，帮我们解决了 Oracle 3 的质量问题。他推出了一款优秀的数据库产品——一款我们引以为傲的产品，一款会让 Ingres 完蛋的产品——Oracle 4”。

当然，这个故事被简单化了。Oracle 4 是一款好产品——当然比满是 bug 的 Oracle 3 要好，但它并不是因为技术上的优势打败了 Ingres，而是因为 IBM 的强大，也因为 Stonebraker 犯了一个错误。

那一年，经过 IBM 和 Oracle 几个月的劝说，美国国家标准协会 (ANSI) 宣布将 SQL 作为标准关系型数据库语言。Symonds 在书中写道：

面对 Oracle 4 的坚不可摧和 Oracle 日益咄咄逼人的销售团队，Ingres 很难保持其势头，但真正的威胁却来自由 IBM 支持的美国国家标准协会 (ANSI) 决定将 SQL 作为标准关系型数据库语言。Mike Stonebraker 甚至不屑于出席委员会会议，为 QUEL 扳回一局，因为在他的意识里，他反对制定任何技术标准。这是一种傲慢的学者行为，而非一个为保护自己公司利益而谨小慎微的商人的行为。埃里森说：“Stonebraker 发明了 QUEL，并像一位自豪的父亲一样坚持使用它，而 IBM 和 Oracle 支持 SQL 标准。不支持 SQL 严重损害了 Ingres，但 Ingres 缺乏可移植性和读取一致性也是问题。Ingres 的性能也远远落后。所有这一切合在一起，扼杀了 Ingres 作为数据库市场竞争者的潜质”。

QUEL 究竟有多好？

Symonds 提到，“很多关系型数据库专家认为它是一种优越的语言”，但即使是这样，仍然低估了 QUEL 在现代关系型数据库先驱们心中的地位。

例如，在 1985 年，也就是 QUEL 和 Ingres 被打败的那一年，数据库传奇人物 C.J.Date——他在 IBM 与 Edgar Codd (关系模型的发明者) 一起研究关系模型——写了一篇论文，他在论文中提到 QUEL 是这两种语言中最好的。

为什么？关键点在于 QUEL 与 Codd 提出的关系演算模型非常接近，而 SQL 不是。QUEL 也是一种精心设计的语言，而 SQL 是由工程师开发的，他们在巨大的压力下匆忙将一个名为 System R 的 IBM 数据库推向市场，以此来证明关系型数据库模型可以成为数据存储系统的可行架构。这在今天看起来有点可笑，但在当时，主流观点认为关系型数据库只不过是一个小玩具。几年后，System R 工程师和 Oracle 的拉里·埃里森证明了关系型数据库就是未来。因此，创建 SQL 的工程师们关注的是数据库性能，而不是语言设计，而且他们从未期望自己发明的接口能够成功并成为标准。

那么 SQL 有什么问题呢？不符合 Codd 提出的关系模型有什么问题吗？

去年年底，我曾与 Holistics 首席工程师 Thanh 进行过一次讨论。他问我：“你对 SQL 有什么看法？”我回答说——就像大多数受过正规训练的程序员一样——“我觉得没问题。你为什么这么问？”

“我认为 SQL 有缺陷”。

“但是 Codd 的关系模型……”

“Codd 的关系模型很棒，但作为该模型的表达式，SQL 是有缺陷的。”

Thanh 在 Slack 的一个评论中解释说：

SQL 不具有可组合性，这是大多数 SQL 用户都不知道的事实。SQL 所基于的关系模型是绝对可组合的，但 SQL 不是，因为它在语言方面存在一些固有的限制 (它的设计类似自然语言)。当你写"select x from a where z"时，实际上是在沿着"from a" => “where z” => "select x"这样的路径构建语句，而且每个部分都可以单独写出来。如果你熟悉 dplyr、Spark 或 Pandas，就会明白这个。

就我所知，QUEL——它更接近 Codd 的关系演算模型——具备离谱的可组合性。我们可能曾经生活在一个 QUEL 和 SQL 相互竞争的世界里，在这个世界里，它们都说自己是“最好的”语言，并找到了自己的利基市场。

但是，世界不是这样运作的。如果世界以另一种方式运作，我们就不会用 QWERTY 键盘打字，也不会说英语了，取而代之的是 Dvorak 键盘和世界语。从那时起，世界已经对 SQL 进行了标准化，而对另一种历史的遐想只存在于那些参与过早期数据库战争的人的头脑中。System R 是由当时计算机行业最强大的公司 IBM 开发的，开发 System R 的工程师们后来又想出了一种复杂的语言接口，IBM 随后采用了这种语言，并推动其成为标准，一直延续到今天。

当然，整个故事还没有结束。Stonebraker 在 1982 年 fork 了 Ingres 代码库创办了自己的公司，在 80 年代惨烈的数据库战争中失败后，他于 1985 年回到伯克利，开始了一个后 Ingres 数据库项目。很自然地，他将这个数据库命名为 Postgres——在 Ingres 之后的意思。

就这样，PostgreSQL 诞生了。

原文链接：

https://www.holistics.io/blog/quel-vs-sql/

关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～