1983年，拉里·埃里森（Larry Ellison）还在一家名为Oracle的小公司工作（当然，现在已经是最大的企业级软件公司了），负责数据库产品bug的修改。殊不知，在后方，计算机科学教授、数据库传奇人物迈克·斯通布雷克（Mike Stonebraker）正在迅速赶上。
后来，马修·西蒙兹（Matthew Symonds）在他的《Softwar》一书中这样说到：
“拉里·埃里森（Larry Ellison）没有把很多注意力放在销售环节上，就埃里森而言，他对甲骨文成功所能做出的最重要的贡献是压倒一切，专注于使产品更好。他根本不认为自己有能力关心首席执行官应该负责的所有其他事情。对于甲骨文公司的某些人来说，埃里森的方法是开明的代表团之一，有人说。“相比于授权，他更接近退位。”当然，从结果看，埃里森确实有充分的理由专注于产品。
与此同时，迈克·斯通布雷克（Mike Stonebraker）立项了他在加州大学伯克利分校监督的Ingres关系型数据库项目，并围绕它成立了一家名为Relational Technology，Inc.（后文简称RTI）的公司。尽管商业版本的Ingres数据库上市时间比甲骨文晚，但迈克·斯通布雷克（Mike Stonebraker）的公司增长反而比Oracle更快。在1984年，Oracle的销售额翻了一番，达到1,270万美元，而随着RTI公司越来越多地知道，Ingres的销售额翻了三倍，达到900万美元。
后来拉里·埃里森（Larry Ellison）说到：“RTI（当时）真的在踢我们的屁股，但他们之所以赶上来是因为我们新的数据库产品变化较大，并且遇到了软件质量问题。”
与Oracle开发SQL相比，Ingres的伯克利团队有更多的时间来完善其用户语言QUEL，许多关系专家认为它本质上是一种高级语言。拉里·埃里森（Larry Ellison）说：“也许QUEL比SQL更好，就像有人认为法语比英语好？但是没关系，SQL和英语一样必胜。”
拉里·埃里森（Larry Ellison）最担心的并不是语言的优越性，而是Ingres大量的人才。“对我来说，很痛苦的是，我们的开发团队不足以跟上Ingres的团队。所以我们不得不重新组建它。如果迈克·斯通布雷克（Mike Stonebraker）从伯克利雇用最好的学生，那我们就从加州理工，麻省理工和斯坦福雇用最好的学生。我们还将在硅谷招募最有经验的编程人才。在一次大变革中，我们还从施乐帕克研究中心（当时很有名的研究机构）聘请了一支精湛的团队，其中有一个人是Derry Kabcenell，他是有史以来在Oracle工作的最重要的人之一。多亏了Derry和他领导的新团队，我们克服了Oracle第三代中的软件质量问题，提供了卓越的数据库产品（我们可以为此感到骄傲），这款产品足以杀死Ingres，也就是我们的Oracle四代。”
当然，这个故事很精简，真实情况远不止这么简单。Oracle 4确实是一个很好的产品，至少比Oracle 3更好，当初Oracle 3向市场发布时，它的bug比废弃的柚子还多。但是4并不是成功的原因，即使它在技术上优于Ingres。
之所以成功，是因为强大的IBM，而且迈克·斯通布雷克（Mike Stonebraker）犯了一个很严重的错误。
Oracle 4发布，在IBM和Oracle的几个月劝说下，美国国家标准协会（ANSI）宣布SQL为标准的关系数据库语言。马修·西蒙兹（Matthew Symonds）写道：
由于Oracle 4的可靠性以及Oracle日益强大的销售力量，Ingres难以维持其发展势头，但真正的威胁是在IBM支持下的美国国家标准学会（ANSI）决定将SQL作为标准的关系型数据库语言。迈克·斯通布雷克（Mike Stonebraker）甚至没有费心出席委员会会议，为采纳QUEL而不是SQL提出（非常有力的）理由，因为他在意识形态上反对设定技术标准。
这是一个学术上傲慢的学者的行为，不是一个谨慎的商人保护他的公司利益的行为。拉里·埃里森（Larry Ellison）说：“ 迈克·斯通布雷克（Mike Stonebraker）发明了QUEL并像一个骄傲的父亲一样坚持下去，而IBM和Oracle支持SQL标准。缺乏SQL支持会严重伤害Ingres，同时缺乏可移植性和读取一致使得Ingres的表现远远落后于其他数据库。所有的这些共同造成了Ingres的没落。”
回到语言本身，QUEL到底有多好？马修·西蒙兹（Matthew Symonds）举了个例子：许多关系专家认为这本质上是一种高级语言，很多人都低估了发明现代关系数据库的先驱者对QUEL的尊重程度。
例如，在1985年QUEL和Ingres失利的那一年，数据库传奇人物CJ Date与IBM关系模型的发明者科德（Codd）一起在IBM的关系模型上工作–写了一篇论文，他认为QUEL是两种语言中的佼佼者。
为什么？争论的关键是，QUEL与科德（Codd）提出的关系演算关系密切，而SQL没有，QUEL还是一种经过精心设计的语言，SQL是由工程师编写的，他们在巨大的压力下将名为System R的IBM数据库推向市场，以证明关系数据库模型可以成为数据存储系统（源）的可行架构。今天看来有点荒谬，但是当时，主流观点认为关系数据库不过是个小玩具而已。System R工程师以及几年后在Oracle任职的Larry Ellison都为他们完成了工作，以证明RDBMSes是未来。因此，创建SQL的工程师专注于数据库性能，而不是语言设计，他们从来没有想到他们发明的用户界面会成为标准。
那么SQL有什么问题？偏离科德（Codd）概述的关系模型有什么问题？
去年下半年，我与Holistics的首席工程师Thanh进行了一次这样的讨论。“您如何看待SQL？” 他问，我就像大多数受过经典训练的程序员所做的那样回答道，“我认为还可以，你为什么要问？”
“哦，我认为SQL有缺陷，科德（Codd）的关系模型很棒。但是，作为该模型的一种表达，SQL是有缺陷的。”
后来Thanh在他撰写的一篇评论中解释道：
“…语言（SQL）不太容易组合。大多数SQL用户都不知道这一事实。SQL所基于的关系代数是绝对可组合的，但是SQL并不是由于语言的固有限制（因为它被设计为类似于自然语言）。当你写“从z的位置选择x”时，实际上是在代数中按照“从a” =>“其中z” =>“选择x”的方式构建对象，实际上你可以分别组成每个部分。如果你熟悉dplyr，Spark或pandas，你将立即获得此信息。”
据我所知，QUEL与科德（Codd）的关系演算关系更为紧密是荒谬的。这个世界并非非黑即白，如果有一个平行世界，在这个世界中，可能QUEL就是现在的SQL，这门“最佳”语言找到了自己的归属。但是，这不是世界运作的方式。如果世界工作方式不同，我们将不再使用现在的键盘书写，也不说英语。像Dvorak和Esperanto这样技术上更好的替代品将被接管。
总之，现在世界已经在SQL上实现了标准化，而替代历史的梦想只存在于那些参与早期数据库战争的人们的头脑中。System R是在IBM（当时计算机行业中最强大的公司）内部构建的，这只是历史的一个怪癖。后来，构建System R的工程师提出了一个怪异的语言界面，这是一个怪癖，然后IBM采纳了该语言并将其推向一种标准，这是一种怪癖……一直持续到今天。
当然，作为传奇，迈克·斯通布雷克（Mike Stonebraker）并没有一直沉寂下去，他于1982年创建了Ingres代码库，从而创建了自己的公司。在80年代激烈的数据库战争打败后，他于1985年返回伯克利，并开始了Ingres后的数据库项目。
接着，PostgreSQL诞生了。
声明：本文由腾讯云数据库产品团队整理翻译，原内容来自于db weekly英文官网（https://dbweekly.com），若转载请注明出处。翻译目的在于传递更多全球最新数据库领域相关信息，并不意味着腾讯云数据库产品团队赞同其观点或证实其内容的真实性。如果其他媒体、网站或其他任何形式的法律实体和个人使用，必须经过著作权人合法书面授权并自负全部法律责任。不得擅自使用腾讯云数据库团队的名义进行转载，或盗用腾讯云数据库团队名义发布信息。因笔者翻译水平有限，翻译过程难免出现纰漏，如有谬误，望各位读者批评指正。
本文由博客一文多发平台 OpenWrite 发布！