SQL标准之争:甲骨文与PostgreSQL背后的江湖恩怨 - holistics

20-10-10 banq

那是1983年,Larry Ellison(埃里森)在一家名为Oracle的小公司工作,专注于重写满是Bug的数据库产品。紧跟其后的是计算机科学教授和最终的数据库传奇人物Michael Stonebraker。

作者Matthew Symonds在他的《Softwar》一书中讲述了这样的故事:

埃里森仍然没有把很多注意力放在销售中正在发生或未发生的事情上。就埃里森而言,他对甲骨文成功所能做出的最重要的贡献是,压倒一切地专注于使产品更好。他根本不认为自己有能力去关心首席执行官应该负责的所有其他事情。对于甲骨文公司的某些人来说,埃里森的方法是开明的代表团之一。

实际上,埃里森有充分的理由专注于产品。Mike Stonebraker接受了他在加州大学伯克利分校监督的Ingres关系数据库项目,并围绕该公司成立了一家名为Relational Technology,Inc.的公司。尽管商业版本的Ingres的上市时间比甲骨文晚一点,但Stonebraker却是比埃里森的增长更快。1984年,Oracle的销售额翻了一番,达到1,270万美元,而随着RTI的日益知名,Ingres的销售额翻了三倍,达到900万美元。

与Oracle开发SQL相比,Ingres的Berkeley团队有更多的时间来完善其用户语言QUEL,许多关系专家认为这本质上是一种高级语言。Ellison说:“也许QUEL比SQL更好。也许法语比英语好?没关系:英语和SQL必胜。” 

埃里森最担心的是Ingres庞大的工程人才。“对我来说,很痛苦的事实是,我们的开发组织还不足以跟上Ingres的团队。所以我们不得不重建它。如果Stonebraker从UC Berkeley雇用最好的孩子,我们将从CalTech,MIT和Stanford雇用最好的孩子。我们还将在硅谷招聘最有经验的编程人才。在一次真正的政变中,我们从施乐PARC聘请了一支精湛的团队。其中一个人Derry Kabcenell,是有史以来在Oracle工作的最重要的人之一。多亏了Derry和他领导的新工程团队,我们克服了Oracle Version 3中的软件质量问题。他提供了卓越的数据库产品(我们可以为此感到骄傲),该产品将杀死Ingres。我们称它为Oracle版本4。”

当然,这个故事是简单的。Oracle版本4是一个很好的产品:肯定比Oracle版本3更好,Oracle版本3向市场发布时,其bug比废弃的柚子还多。它并不是在技术上优于Ingres。它之所以成功,是因为IBM强大,而且Stonebraker犯了一个错误。

后来,在IBM和Oracle的几个月劝说下,美国国家标准学会(ANSI)宣布SQL为标准的关系数据库语言。西蒙兹写道:

由于第4版的可靠性以及Oracle日益强大的销售力量,Ingres难以维持其发展势头,但真正的威胁是在IBM支持下的美国国家标准学会(ANSI)决定将SQL声明为标准关系数据库。语言。Ingres的Mike Stonebraker甚至没有出席委员会会议,也没有为力争采纳QUEL提出(非常有力的)理由,因为他在意识形态上反对设定技术标准。这是一个学术上傲慢的学者的行为,而不是一个谨慎的商人保护他的公司利益的行为。

埃里森说:“ Stonebraker发明了QUEL并像一个骄傲的父亲一样坚持下去,而IBM和Oracle支持SQL标准。缺乏SQL支持会严重伤害Ingres。致使其缺乏可移植性和读取一致性。而且Ingres的表现远远落后。所有这些共同举措企图杀死Ingres,不让其成为数据库市场的竞争对手。”

 

QUEL真有那么好?

许多关系专家认为QUEL本质上是一种高级语言,例如,在1985年QUEL和Ingres失利的那一年,数据库传奇人物CJ Date (与IBM关系模型的发明者Edgar 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的关系模型?”

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

Thanh在他撰写的Slack评论中(在不同的背景下以及将近一年后)解释道:

…语言(SQL)不太容易组合。这是大多数SQL用户都不知道的事实。SQL所基于的关系代数是绝对可组合的,但是SQL并不是由于语言的固有限制(因为它被设计为类似于自然语言)。当您编写"select x from a where z",时,实际上是沿着代数中的"from a" => "where z" => "select x"的线构建东西,实际上您可以分别组成每个部分。如果您熟悉dplyr,Spark或pandas,您会立即获得。

当然,整个传奇故事有一线希望。Stonebraker于1982年创建了Ingres代码库,从而创建了自己的公司。在80年代激烈的数据库战争失败后,他于1985年返回伯克利,并开始了Ingres后的数据库项目。当然,他命名数据库为post-gres,Ingres之后。

因此PostgreSQL诞生了。

 

                   

1
猜你喜欢