前沿觀察 | 數據庫戰爭往事

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 發佈！