1992 年，31 歲的 D. Richard Hipp 在 Hwaci. 公司負責技術開發，他的專項團隊中有一個客戶是巴斯鋼鐵廠，負責為 DDG-79 Oscar Austin 號開發軟件——那是一艘龐大、復雜、隨時都會出毛病的戰艦。

當時的數據庫 Informix 運行得并不好，有時候服務器會宕機，導致應用程序無法運行。船員雙擊這款軟件后會彈出對話框報錯：“無法連接到數據庫服務器”，而負責此項目的 Richard 團隊對此無可奈何，因為他們無權控制數據庫服務器。

Richard 之所以被選中，是因為他向來以能解決難題而聞名。“頭頂著技術團隊的名號，出的問題還是要由我們背鍋，畢竟對話框這塊可是我們負責的?！盧ichard 說道。

Richard 團隊的思路是哪怕在戰斗中受損，整個船舶系統也應該能夠正常工作，因此數據庫必須可靠。事實上，他們做的事情很簡單，就是把數據讀入 RAM——不做事務處理、不做任何類似的操作，只是把數據拉入內存。

這給了 Richard 這樣的領悟：我們為什么非得需要服務器？為什我不能直接從磁盤驅動器上把數據提取出來？這樣如果計算機運行狀態良好，它就能運行應用程序，整個流程中不再存在可能導致失敗的依賴項。

但四處打探后，他發現當時根本就沒有能做到這一點的 SQL 數據庫引擎。之后，Richard 的一位同事提醒道：

“Richard，你為什么不自己寫一個呢？”

“行啊，我試試吧。”

Richard 回應了，但并沒有立馬動手。2000 年左右，公司資金中斷，當時恰逢紐特·金里奇和比爾·克林頓就國會預算案發生了爭執，導致所有政府合同都被取消了，Richard 被迫失業了好幾個月。

“閑著也是閑著，正好來寫那個數據庫引擎?！本瓦@樣，Richard 開始了 SQLite 的研發。

2000 年時，人們主要使用撥號上網，只有 1% 的美國家庭擁有網絡帶寬，因此 Richard 不像現在的人們那樣可以谷歌搜索學會構建數據庫。

但他根據自己先前的編譯器構建經驗制定了一項清晰的計劃：如果把每一條 SQL 語句視為一個程序，那自己的任務就是把這些程序編譯成某種可執行的代碼。

因此，Richard 編寫了一套能夠實際運行查詢的字節碼引擎，之后又編寫了一款編譯器，用于將 SQL 轉換成相應的字節碼。就這樣，SQLite 誕生了。

可惜它并沒有在 Richard 當時從事的戰艦項目上發揮作用，因為那個項目被關閉了。后來項目重啟，Richard 嘗試把 SQLite 引入其中進行測試。不過遺憾的是客戶堅持使用 Informix?！暗故强梢岳斫猓?Informix 在開發方面的使用感受真的很差?！盧ichard 說道。

為了不浪費，Richard 把它放在了互聯網上，于是有更多人開始使用。“當時還沒有 Twitter 之類的東西，但已經有帖子說‘哇，我在自己的 Palm Pilot PDA 設備上運行 SQL 數據庫啦！’不開玩笑，這樣的事情當時確實吸引到很多人的關注，這也激勵著我繼續做研究和開發?！盧ichard 表示。

“我最早開始編寫 SQLite 的時候，曾經到處搜尋，想要看看有沒有關于如何編寫 SQL 數據庫引擎的參考資料?？晌沂裁炊紱]找到，所以只能邊做邊學邊發明。這是個完全由自己摸索出來的路徑?！盧ichard 說道。

大部分理論都是由麻省理工學院、哈佛大學、劍橋大學或者伯克利大學的研究小組提出的，而如果大家沒上過這些學校，就很可能完全沒聽說過這些理論，更沒有靠譜的方式能夠查詢相關資料。

但奇怪的是，如果回頭看看 Postgres 使用的火山模型和 SQLite 曾經使用的字節碼模型，就會發現大家都不約而同選擇了類似的方向。這些方案雖然從宏觀來講起點各不相同，但大家在如何提高速度表現方面卻意見統一，所以 Richard 認為這也是對理論的一種印證，兩條獨立的開發路徑得出了同樣的答案。

例如，Richard 就從來沒聽說過覆蓋索引。只是在一場位于德國的 PHP 大會上，他見到了 MySQL 初創團隊成員之一的 David Axmark，Axmark 解釋了 MySQL 是如何實現覆蓋索引的。Richard 想，“哇哦，這個想法簡直天才！”于是在回途的飛機上就開始為 SQLite 編寫覆蓋索引。

“其實我只是在到處借鑒?！盧ichard 說道，人們會分享自己的心得，有人會主動找他：

“你為什么不試試這種優化方法？”

“我沒想到啊?！?/section>

“那你看能行嗎？”

“那就試試唄。”

之后它就成了 SQLite 的一部分。這就是邊做邊學邊發明的好處。

SQLite 開發出來的頭一兩年，Richard 忙于推進他的數據庫項目。突然，有一天他接到了當時科技巨頭摩托羅拉打來的電話。

“你好，我們正在設計一款新的手機操作系統，而且打算將 SQLite 納入其中。你能為我們提供支持嗎？”

“哦，可以的。我沒問題?！?/section>

“那能不能給報個價？”

“好的，這樣吧，明天咱們再打個電話，到時候我給你答復?！?/section>

當時 Richard 的內心一陣狂跳——居然還能靠做開源軟件賺錢？真有這樣的事？我該定多少錢？怎么辦怎么辦……Richard 四下搜索，想出了幾種定價策略。摩托羅拉當時還有改進要求，需要適應手機硬件，于是 Richard 報了 8 萬美元左右?！霸诋敃r的我看來，那數字簡直就是在明搶，可以說貴得離譜?！?/p>

后來，Richard 又找來三位前同事一起做這個項目，而這就是 SQLite 項目起飛的原點。

而真正讓 SQLite 走上成功道路的是諾基亞手機的操作系統塞班。塞班打電話希望 Richard 在感恩節那天能飛一趟倫敦總部。去了之后，Richard 才發現，塞班之前已經搞了一場大規模的招標，從中挑選出塞班系統的數據庫引擎。

當時參加選拔的大約有 10 種不同的數據庫引擎，其中有兩款是開源項目，另外七款屬于專有產品。塞班在數據集上運行了這些引擎，想看看哪種最適合自己的需求，最后 SQLite 順利勝出。塞班還給了其他九家調整的機會，但最后又是 SQLite 贏了。

Richard 過去后，塞班的人對 SQLite 大加贊賞，同時又提出了一些改進要求。之后，雙方簽訂了合同，由 Richard 負責做相應的開發。

當時 Richard 幾人真的是盡心盡力，Richard 本人差不多是全職在做這方面工作了。

但是，后來塞班的人告訴他們：“不好意思，你得想辦法提高巴士因子。”他們覺得 SQLite 的巴士因子不夠……所以希望建立一個 SQLite 聯盟，讓更多人參與進來以保證項目長期存續。

注：所謂巴士因子，就是說一支團隊里有多少成員意外被巴士撞了（或者受其他偶發因素影響而無法繼續工作），才會導致項目陷入停滯。

接到需求后，Richard 開始推動這項重要工作，但他其實也不知道該怎么做。后來，當時 Mozilla 基金會的負責人 Michell Baker 聽到了風聲，主動給他打電話說：“Richard，你的做法有問題，讓我來告訴你怎么建立一個聯盟。”

Baker 制定了規則，強調“開發者必須掌控一切，開發者的決定就是最終決定。對于批準哪些內容加入項目，其他人沒有投票權。企業參與者只有享受成果和貢獻資金的榮譽頭銜，但決定還是要由你自己掌握?！彼龑Υ朔浅远ǎ覍ξ铱梢哉f是知無不言、言無不盡。

Baker 是律師出身，我問她“那要怎么吸引人們加入？得設置怎樣的激勵措施？”她回答道，“別擔心，人們肯定會加入的。只要按我的辦法來，Mozilla 首先就會成為創始成員之一?！倍诼撁擞媱澒己螅晃搅?Mozilla、塞班和 Adobe 的支持，各方共同成立了 SQLite 聯盟。

值得一提的是，SQLite 的版權聲明中還有一條：Open-Source, not Open-Contribution（開源，但是并不開放代碼貢獻）。因此，至今 SQLite 項目總共只有三位開發人員 D. Richard Hipp、Dan Kennedy 和 Joe Mistachkin。

構建智能手機這樣的嵌入式開發是個緩慢的過程，需要長時間的迭代循環，更需要花時間等待各種功能在原型設計中一一體現，人們只能在看起來跟成品完全不同的“坯子”上進行開發。

谷歌聯系了 Richard，當時的搜索巨頭還跟手機或者嵌入式開發牽不上半點關系。

2005 年左右，Richard 幾人正在跟 Android 開會，那時候這款如今聲名大噪的操作系統還沒真正出現，當時也沒有 iPhone。那時候的手機下方是完整的 QEWRTY 全鍵盤，上方則是個較小的顯示窗口。

Richard 團隊使用 SQLite 進行調試：端連著手機，另一端在工作站上運行調試器?！斑@種感覺挺神奇的。其他人都不會干，而當我們把手機接入調試器時，電話響了。這位同事看了一眼說，‘哦，是我老婆，我得接個電話，不好意思?！译x開了房間，留他慢慢跟妻子聊天?！?/p>

當時 Richard 雖然表面上不露聲色，但腦袋里卻炸開了鍋?！拔覀兙尤辉诮又簿W絡的手機上調試應用程序，而且完全不耽誤正常通話，這真是太令人震驚了。無論是摩托羅拉、塞班還是諾基亞，當時都沒人能做到這一點。就在那個瞬間，我就知道 Android 絕對會大獲成功?！?/p>

不過幸福之后，煩惱也會隨之而來。

“我們曾經天真地宣傳，SQLite 從不出錯，至少不會搞出嚴重的 bug。但 Android 證明我們還是太過年輕、有時幼稚。我以前真的以為能編寫出沒有 bug 的軟件，可一旦軟件被發布到數百萬臺設備上時，引發的 bug 數量絕對會多到難以想象?！盧ichard 回憶道。

當時還在為航空電子設備制造商 Rockwell Collins 工作的 Richard，了解到了 DO-178B 的概念，他意識到其中最有價值、最關鍵的理念之一，就是要求實現 100% 的 MCDC 測試覆蓋率。

注：MCDC，指的是確定代碼修改條件的決策覆蓋率。也就是說測試必須保證所生成二進制代碼中的每個分支操作至少跑通一次。

受到啟發后的 Richard 決定通過編寫測試讓 SQLite 也達到 100% 的 MCDC 覆蓋率，而這花了他整整一年的時間，每周要工作 60 個小時。

“這項工作相當相當艱苦，我每天要干 12 個小時。這段經歷真的讓我感到厭倦，而且相信大家都聽過一句老生常談：我們用前 95% 的預算干完了 95% 的工作，再用另外 95% 的預算做完最后 5%。實際情況確實如此，把測試覆蓋率推到 90% 甚至 95% 都很容易，可最后這 5% 則是難而又難，我花了大約一年時間才達成這個目標。”Richard 回憶時說道。

對于典型的發布周期，他們要運行十億級別的測試，大約有 10 萬個不同的測試用例。他們的第一項測試是用 TCL 編寫的，真正 100% 覆蓋的 MCDC 測試名叫 TH3，屬于專有成果。Richard 本來希望把這些測試出售給航空電子設備制造商賺點錢，但一份都沒賣出去。

團隊有一個叫 SQL 邏輯測試的工具，目的是設法讓每種數據庫引擎都出現段錯誤，其中也包括 SQLite?！拔覀兏惚肋^ Oracle，包括 Oracle 的商用版本。我們搞崩過 DB2，嘗試把我們能接觸到的所有數據庫并努力把它搞崩。”Richard 提到，唯一的例外就是 Postgres，它的穩定性給 Richard 留下了非常深刻的印象。

總之，提高測試覆蓋率成了一項深遠影響的決策，Richard 團隊在接下來的八、九年里再也沒遇到過任何 bug。

SQLite 基本上全都是 Richard 親自動手開發的依賴項。除了 C 編譯器和 libc 之類的現成方案，他甚至構建了自己的源代碼控制系統和 bug 跟蹤器?？傊?，Richard 的項目都由他來掌握。

“人們去背包旅行或徒步，表面上看是種自由，但實際上途中到底如何取決于他們的背包準備得是否充足。因此，他們討論的自由其實就是自己到底為此付出了多少心力?！盧ichard 說道，“所以當我們編寫自己的項目時，肯定可以享受其中的自由、不再受到其他人的約束。畢竟我們不依賴于不同供應商直接提供的現成方法?！?/p>

就像當初選擇使用本來開源的 Berkeley DB 作為 SQLite v2 版本的存儲引擎的話，當它被賣給甲骨文、成了雙源專有模型后，本來理想的情況就變得相當被動。

SQLite 中的解析器生成器 Lemon 是多年之前 Richard 親手編寫的?！懊慨斘倚枰恍o法從 Yacc 或者 GNU Bison 處獲得的新型語言功能時，由于擁有對解析器生成器的掌控權，我可以隨時調整 SQLite 的版本控制系統并做出自己想要的調整?！?/p>

他最初使用 CSV，因為 2000 年那會兒每個項目都在使用 CVS， 而進入 2000 年代中期后則需要更好的系統。Richard 先后研究了 Git、Mercurial，又回顧了自己的需求，突然發現“得自己寫一個才行”。于是 Richard 編寫了自己的版本控制系統，而現在它本身也成了獨立的項目，而且效果非常好。

“因為是自己親力親為，所以它能夠充分滿足我的需求，可以跟一切原有、現有及未來將要出現的工作場景相契合?！盧ichard 說道，“這種自己動手方式能把命運把握在自己指尖，以擺脫第三方的方式真正擁抱自由?！?/p>

原文鏈接：

https://corecursive.com/066-sqlite-with-richard-hipp/