SQL標準之爭：甲骨文與PostgreSQL背後的江湖恩怨 - holistics

banq發表於2020-10-10
SQL

那是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誕生了。



 

相關文章