SQL 半世紀演進史

如今，多數主流關聯式資料庫都支援 SELECT 查詢。這種跨產品的共通性，容易讓人誤以為 SQL 從一開始就是資料庫的標準語言。

然而，回顧半世紀前的電腦世界，資料庫領域充斥著彼此互不相通的私有介面。SQL 之所以能成為跨越數十年、支配產業的共同標準，並非因為它是當時唯一的方案，而是經歷了一場長達數十年的技術接力：從數學理論出發，歷經系統工程的嚴苛驗證，再到商業市場的激烈競爭與國際規範的確立。

這段歷程展示了一種語言如何打破硬體與廠商的壁壘，重塑整個軟體產業的資料思維。

先分清關聯模型、SQL 語言與資料庫產品

要理解 SQL 的演進，首先必須區分三個經常被混為一談的概念：關聯式模型、SQL 查詢語言與資料庫產品。

 +-----------------------+
 |   Relational Model    |
 |    (Data Concept)     |
 |     Codd (1970)       |
 +-----------------------+
             |
             v
 +-----------------------+
 |     SQL Language      |
 |    (Query Syntax)     |
 |    SEQUEL (1974)      |
 +-----------------------+
             |
             v
 +-----------------------+
 |   Database Products   |
 |   (Storage Engine)    |
 | System R, Oracle, Db2 |
 +-----------------------+

1970 年，IBM 研究員 E. F. Codd 發表了劃時代的論文《A Relational Model of Data for Large Shared Data Banks》。在那個由階層式（Hierarchical）與網狀（Network）資料庫主導的年代，應用程式必須清楚知道資料在磁碟中的實體存放位置與指標路徑。

Codd 提出的核心觀念是「資料獨立性」（Data Independence）：使用者只需關心資料之間的邏輯關聯，無須依賴底層儲存結構。當底層儲存格式或索引改變時，業務查詢邏輯不必跟著修改。

這份論文以數學上的關聯代數與關聯演算為基礎，確立了理論框架，但尚未定義今日工程師所熟悉的文字查詢語法。

不過，關聯模型與 SQL 並不完全相同。數學上的關聯是集合，不會有重複元素；但 SQL 查詢預設會保留重複的資料列，要加上 DISTINCT 才會消除。換句話說，SQL 以關聯模型為藍本，卻不是它的逐字翻譯。

SEQUEL 誕生：用英語關鍵字查詢資料

有了關聯式模型後，下一步是設計出一套好用的操作語言。1974 年，IBM 研究員 Donald Chamberlin 與 Raymond Boyce 發表了論文《SEQUEL: A Structured English Query Language》。

當時的研究者希望避開形式邏輯中艱澀的數學符號（如量詞與集合運算），改用接近結構化英語的關鍵字模板，讓工程師與一般業務分析人員都能輕鬆表達需求：

SELECT c.name, o.amount
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
WHERE o.amount >= 1000;

宣告式語言（Declarative Language）的魅力在於：使用者只需要宣告「要什麼」（What），而將「怎麼做」（How）完全交由系統處理。

研究者當時還透過一項小規模實驗，檢驗 SEQUEL 是否比較容易學。1975 年，Phyllis Reisner、Boyce 與 Chamberlin 找來大學生做人因實驗，比較 SEQUEL 與帶有數學下標的 SQUARE。

上課 12 至 14 小時後，兩種語言都能學到一定程度，而沒有程式背景的學生用 SEQUEL 表現較好。不過 GROUP BY 這類功能依然難學。

IBM 隨後在 XRM 關聯式記憶體（Relational Memory）之上打造了 SEQUEL 原型直譯器，驗證語意表達。後來因為 SEQUEL 已是英國航太公司 Hawker Siddeley 旗下企業的註冊商標，團隊拿掉母音，改稱今日眾所皆知的「SQL」。

System R：在真實工程中驗證可行性

XRM 上的原型直譯器證明了語法可行，但在 1970 年代產業界仍面臨巨大的技術質疑：若只說「要什麼」，電腦真的能在合理時間內算出最佳存取路徑嗎？若效能低落，再漂亮的語法也無法走出實驗室。

為了解答這個工程難題，IBM 啟動了名為 System R 的實驗性專案，旨在真實的磁碟儲存與多使用者環境下驗證關聯式資料庫的可行性。1976 年的系統論文涵蓋檢視表、權限、完整性、交易、日誌與復原等設計，並明言它是研究載體，不是預定推出的產品。

System R 最關鍵的突破，是 1979 年 Patricia Selinger 等人研發的成本式查詢最佳化器。以前面的訂單查詢為例：先找出金額達標的少數訂單再對應顧客，或先讀遍兩張表再比對，花費可能天差地遠。

最佳化器依據資料統計估算 CPU 與 I/O 成本，替使用者挑選讀取路徑與連接順序。它不保證每次都挑到理論上的最佳解，但把「怎麼做」的負擔從查詢者身上轉交給系統。

這也讓資料獨立性真正派上用場。訂單變多時，管理員可以新增索引，資料庫隨之調整執行計畫，業務查詢一行都不用改。當然，索引、統計資料與各家最佳化器仍會影響效能，SQL 並不保證寫一次就永遠不必調校。

此外，團隊也補齊了權限授權與檢視表機制，處理資料表的授權與撤銷，讓多人能安全地共享同一份資料。

企業也需要讓 SQL 用在日常執行的程式中，而不只是在終端機上臨時查詢。System R 團隊驗證了 SQL 能同時服務兩種用法：終端機上的臨時查詢，以及嵌入 PL/I、COBOL 程式中反覆執行的交易。對後者，系統會在執行前先完成語法解析與路徑選擇，交易每次執行時就不必重做這些工作。

System R 的成功緩解了產業界對效能的疑慮，也為 SQL 走向商用產品奠定基礎。

商業化浪潮：市場跑在標準前面

看到 System R 的研究成果後，敏銳的創業者意識到巨大商機。當時 IBM 因顧慮既有主機階層式資料庫（IMS）的利潤而對商業化持審慎態度，並將研究論文公開發表。

1979 年，由 Larry Ellison、Bob Miner 與 Ed Oates 共同創立的 Relational Software（即後來的 Oracle）根據公開論文搶先推出全球首個商用 SQL 資料庫 Oracle V2，甚至比 IBM 官方產品更早上市。

面對市場競爭，IBM 隨後於 1981 年發表 SQL/DS，並在 1983 年推出支援大型主機的旗艦產品 Db2。

這段時期呈現出獨特的現象：商用產品的推廣完全走在官方標準制定之前。各家廠商根據論文自行實作 SQL 引擎，大幅加速了市場普及，但也埋下了語法擴充與實作差異的種子。

競爭對手的抉擇：Ingres 與 QUEL 的退場

在關聯式資料庫的探索初期，SQL 並不是唯一的候選人。同時代加州大學柏克萊分校開發的 Ingres 系統，採用了另一套名為 QUEL 的查詢語言。

在許多技術專家的眼中，QUEL 基於嚴謹的元組關聯演算（Tuple Relational Calculus，以單筆記錄為基礎的邏輯運算），設計比早期的 SQL 更加簡潔且語意一致。然而，隨著 IBM 與 Oracle 在商業上的成功推廣，採購客戶與軟體生態開始全面向 SQL 傾斜。

史料紀錄揭示了這場變革的現實面。一份約 1985 年的 Ingres 內部銷售文件顯示，儘管開發團隊堅信 QUEL 在技術上更優，但為回應客戶強烈的採購要求，Ingres 不得不妥協提供 SQL 介面。

SQL 共同發明人 Chamberlin 在口述歷史中描述了同樣的走向：原本使用 QUEL 的產品先把 SQL 當成替代介面，之後才轉為主要介面。他也特別指出，逐漸一致的是使用者看到的語言，底層技術仍由各家自行研發。

到了 1988 年，Ingres 官方文件已將 SQL 明列為業界標準。同樣地，PostgreSQL 的前身 POSTGRES 原本採用 PostQUEL，也在 1995 年改用 SQL。

Ingres 與 POSTGRES 先後加入 SQL 介面，顯示當時的市場需求與軟體生態，比開發者對查詢語言的設計偏好更能左右產品選擇。

標準化之路：從共同語感到國際規範

市場越來越偏向 SQL，標準化組織也開始制定正式規範。標準確立後，SQL 的採用範圍進一步擴大：

• 1986 年：美國國家標準學會（ANSI）發布了首個 SQL 官方標準。
• 1987 年：國際標準化組織出版 ISO 9075:1987，確立了 SQL 的全球標準地位。
• 1987 年：美國國家標準與技術研究院（NIST）核准 FIPS 127，將 SQL 納入聯邦政府採購的檢驗標準，為 SQL 提供了強大的制度推動力。

FIPS 127 讓標準走進了符合性檢測。NIST 在 1995 年公布的驗證產品清單，收錄了依聯邦標準測試過的 SQL 產品。從此廠商不能只說「我有 SQL」，還得回答「我符合哪份規範、如何證明」。

此後，標準持續演進：1992 年的 SQL-92 奠定了今日最常見的核心語法，並把相容程度分成 Entry、Intermediate、Full 三級；1999 年的 SQL:1999 改用「核心功能」與「選用套件」的相容性框架；直到最新的 SQL:2023，持續納入 JSON 與屬性圖查詢等現代需求。

Chamberlin 在訪談中提到，標準讓工具、書籍與課程有了共同的市場。出版品、教學課程、ORM 工具與開發者技能因此得以通用，大幅降低了跨系統的學習與整合成本。

結語：SQL 的共同標準與實作差異

有了 SQL 標準，各家資料庫的寫法仍不完全相同。光是取出前五筆訂單，就可能遇到兩種寫法：

-- PostgreSQL 與 MySQL 習慣的方言寫法
SELECT id, amount
FROM orders
ORDER BY amount DESC
LIMIT 5;

-- SQL:2008 標準定義的寫法（PostgreSQL 同樣支援）
SELECT id, amount
FROM orders
ORDER BY amount DESC
FETCH FIRST 5 ROWS ONLY;

依 PostgreSQL 官方文件，LIMIT 是產品擴充，FETCH FIRST 則是 SQL:2008 標準語法。廠商在標準出爐前各自實作，也持續加入自己的功能；既有程式依賴這些寫法，方言便不會因為標準公布而消失。差異甚至延伸到連線方式與錯誤處理，不能只看查詢語法，就認定整個應用程式能原封不動搬家。

從 Codd 的模型、System R 的驗證，到商用產品與國際標準接力，SQL 讓開發者能用一套基本語言與不同資料庫溝通。這是它半世紀來最重要的勝利。換用另一套資料庫時，仍要確認程式依賴的是標準核心、選用功能，還是某家產品的擴充。SQL 統一了基本查詢語言，沒有保證應用程式能直接換資料庫。