1970年，IBM研究員Edgar F. Codd在《Communications of the ACM》上發(fā)表了一篇12頁(yè)的論文。沒(méi)人想到，這個(gè)看似枯燥的數(shù)學(xué)模型會(huì)成為此后半個(gè)多世紀(jì)數(shù)據(jù)管理的絕對(duì)主流——直到今天，你手機(jī)里的銀行App、電商訂單、醫(yī)院掛號(hào)系統(tǒng)，底層大概率還在跑著他設(shè)計(jì)的這套東西。

關(guān)系模型（Relational Data Model）的本質(zhì)，是把所有數(shù)據(jù)塞進(jìn)一張張二維表格，用行和列的數(shù)學(xué)關(guān)系來(lái)回答一切業(yè)務(wù)問(wèn)題。

聽(tīng)起來(lái)像Excel？差遠(yuǎn)了。Codd的洞見(jiàn)在于：他證明了一門(mén)叫關(guān)系代數(shù)（Relational Algebra）的數(shù)學(xué)工具，足以表達(dá)任意復(fù)雜的數(shù)據(jù)查詢。這意味著數(shù)據(jù)庫(kù)可以不管數(shù)據(jù)物理上怎么存，只暴露一套純粹的邏輯接口。用產(chǎn)品的話說(shuō)，這是最早的"存儲(chǔ)與計(jì)算分離"架構(gòu)。

從論文到產(chǎn)品：Oracle如何用7年把理論變成生意

1979年，Larry Ellison的公司（當(dāng)時(shí)還叫Relational Software）發(fā)布了Oracle V2，這是第一個(gè)商用的關(guān)系數(shù)據(jù)庫(kù)。注意這個(gè)時(shí)間——Codd的論文發(fā)表9年后，IBM自己還在用層次型數(shù)據(jù)庫(kù)IMS，反倒是這個(gè)硅谷創(chuàng)業(yè)公司把理論落地了。

Oracle的打法很產(chǎn)品經(jīng)理：先支持SQL（Structured Query Language，結(jié)構(gòu)化查詢語(yǔ)言），再把Codd的12條規(guī)則（后來(lái)擴(kuò)展到13條）當(dāng)成營(yíng)銷(xiāo)彈藥。1986年，SQL成為ANSI標(biāo)準(zhǔn)；1987年，成為ISO標(biāo)準(zhǔn)。關(guān)系模型至此完成從學(xué)術(shù)概念到行業(yè)基礎(chǔ)設(shè)施的躍遷。

這套架構(gòu)的核心組件至今沒(méi)變：

表（Table）是原子單元。每張表代表一個(gè)實(shí)體類(lèi)型——用戶、訂單、商品。行（Row，Codd叫Tuple/元組）是一條記錄，列（Column，Codd叫Attribute/屬性）是這條記錄的某個(gè)特征。

每個(gè)屬性必須聲明數(shù)據(jù)類(lèi)型：整數(shù)、文本、日期、布爾值。這是域（Domain）約束——一列里不能混著存數(shù)字和字符串，就像Excel單元格可以亂填，但數(shù)據(jù)庫(kù)會(huì)當(dāng)場(chǎng)報(bào)錯(cuò)。

模式（Schema）是數(shù)據(jù)庫(kù)的藍(lán)圖。它定義有哪些表、每張表有哪些列、列的數(shù)據(jù)類(lèi)型、表與表之間怎么關(guān)聯(lián)。關(guān)鍵區(qū)分：模式（Schema）是設(shè)計(jì)圖紙，實(shí)例（Instance）是圖紙?jiān)斐鰜?lái)的房子。同一張表，今天有1000行，明天插入500行，模式不變，實(shí)例變了。

鍵（Keys）：關(guān)系模型的"社會(huì)信用碼"

沒(méi)有鍵，關(guān)系模型就塌了。鍵是一列或幾列的組合，用來(lái)唯一標(biāo)識(shí)一行數(shù)據(jù)，并在表與表之間建立關(guān)聯(lián)。

主鍵（Primary Key）是表的身份證。用戶表用user_id，訂單表用order_id。規(guī)則很?chē)?yán)：不能重復(fù)，不能為NULL。一個(gè)用戶可以有多個(gè)收貨地址，但user_id必須唯一確定這個(gè)人。

外鍵（Foreign Key）是跨表關(guān)聯(lián)的鉤子。訂單表里的user_id列，引用用戶表的user_id主鍵。數(shù)據(jù)庫(kù)會(huì)自動(dòng)檢查：你插一條訂單，如果user_id在用戶表里不存在，直接拒絕——這叫引用完整性（Referential Integrity）。

候選鍵（Candidate Key）是"可以當(dāng)主鍵但沒(méi)選上的列"。用戶表除了user_id，郵箱也可能唯一，但設(shè)計(jì)時(shí)選了user_id做主鍵，郵箱就成了候選鍵。復(fù)合鍵（Composite Key）是多列組合當(dāng)鍵，比如（user_id + 地址類(lèi)型）唯一確定一個(gè)收貨地址。

Codd的原始論文里，關(guān)系（Relation）這個(gè)詞來(lái)自數(shù)學(xué)——一張表就是一個(gè)關(guān)系，行是關(guān)系的元素，列是關(guān)系的域。所以"關(guān)系型數(shù)據(jù)庫(kù)"不是指表與表之間的關(guān)系，而是指數(shù)據(jù)本身滿足數(shù)學(xué)上的關(guān)系定義。這個(gè)命名坑了無(wú)數(shù)初學(xué)者。

規(guī)范化：用冗余換一致性，還是反過(guò)來(lái)？

1971年，Codd提出了第一范式（1NF）；1974年，第二、第三范式跟進(jìn)。規(guī)范化（Normalization）的目標(biāo)很明確：消除數(shù)據(jù)冗余，避免更新異常。

經(jīng)典例子：把"用戶+訂單"大表拆成用戶表和訂單表。用戶換手機(jī)號(hào)，只改一行；否則每個(gè)歷史訂單里都要改一遍，漏一個(gè)就數(shù)據(jù)不一致。

但規(guī)范化有代價(jià)。查詢一個(gè)用戶的全部訂單，要JOIN兩張表；訂單量上億時(shí)，JOIN成本可能拖垮系統(tǒng)。反規(guī)范化（Denormalization）因此成為工程常態(tài)——故意存冗余數(shù)據(jù)，用空間換時(shí)間。

電商大促前，把用戶最近訂單緩存進(jìn)Redis；報(bào)表系統(tǒng)里，預(yù)計(jì)算好"用戶-訂單-商品"的寬表。這些都不是關(guān)系模型的理論，是工程師在真實(shí)壓力下的妥協(xié)。

約束（Constraints）是數(shù)據(jù)庫(kù)的守門(mén)員。除了主鍵、外鍵，還有檢查約束（CHECK，比如年齡必須>0）、唯一約束（UNIQUE，比如郵箱不能重復(fù)）、非空約束（NOT NULL）。這些在應(yīng)用層也能做，但數(shù)據(jù)庫(kù)層強(qiáng)制執(zhí)行是最后一道防線。

SQL：被吐槽了40年，為什么還活著？

SQL的設(shè)計(jì)很"70年代"：聲明式語(yǔ)法，你只需要說(shuō)"要什么"，數(shù)據(jù)庫(kù)自己決定"怎么拿"。對(duì)比當(dāng)時(shí)的COBOL文件操作，這是降維打擊。

但SQL也被罵了40年。三值邏輯（TRUE/FALSE/UNKNOWN）讓NULL處理變成玄學(xué)；缺乏真正的模塊化，存儲(chǔ)過(guò)程寫(xiě)成面條代碼；標(biāo)準(zhǔn)更新慢，各廠商方言叢生。NoSQL運(yùn)動(dòng)在2009年爆發(fā)，MongoDB、Cassandra、Redis集體喊出口號(hào)：干掉關(guān)系模型。

結(jié)果呢？MongoDB 4.0加了多文檔事務(wù)；Cassandra引入輕量級(jí)事務(wù)；Redis有了RedisJSON和RediSearch。NoSQL們?cè)?一致性-可用性-分區(qū)容錯(cuò)"的CAP三角里兜了一圈，發(fā)現(xiàn)金融、醫(yī)療、政務(wù)這些場(chǎng)景，最終一致性根本不夠用。

2024年的數(shù)據(jù)庫(kù)版圖：關(guān)系模型仍是結(jié)構(gòu)化數(shù)據(jù)的主宰，但邊界在收縮。

云原生時(shí)代，Snowflake、BigQuery把存儲(chǔ)和計(jì)算徹底分離；TiDB、CockroachDB用Raft共識(shí)實(shí)現(xiàn)分布式事務(wù)；PlanetScale給MySQL加了分支schema變更。這些創(chuàng)新都在關(guān)系模型的框架內(nèi)——Codd的表格+鍵+SQL，只是底層實(shí)現(xiàn)換了無(wú)數(shù)輪。

真正擠壓關(guān)系模型空間的，是數(shù)據(jù)形態(tài)的爆炸。日志、圖片、視頻、傳感器流、大模型向量——這些非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)，表格塞不進(jìn)去。向量數(shù)據(jù)庫(kù)（Pinecone、Milvus）、時(shí)序數(shù)據(jù)庫(kù)（InfluxDB、TimescaleDB）、圖數(shù)據(jù)庫(kù)（Neo4j）各自切走一塊蛋糕。

但關(guān)系模型的護(hù)城河很深。ACID事務(wù)（原子性、一致性、隔離性、持久性）是金融系統(tǒng)的剛需；SQL的生態(tài)——BI工具、ORM框架、分析師技能?！w移成本極高；schema的強(qiáng)約束，在數(shù)據(jù)治理越來(lái)越嚴(yán)的今天，反而成了優(yōu)勢(shì)。

2023年，Gartner估計(jì)全球數(shù)據(jù)庫(kù)市場(chǎng)規(guī)模超過(guò)1200億美元，關(guān)系型產(chǎn)品占比仍超75%。PostgreSQL連續(xù)6年被評(píng)為"年度數(shù)據(jù)庫(kù)"，MySQL仍是Web應(yīng)用默認(rèn)選項(xiàng)。Codd的遺產(chǎn)，比他自己想象的更頑固。

一個(gè)細(xì)節(jié)：Codd晚年為什么和IBM鬧翻？

1980年代，Codd離開(kāi)IBM，創(chuàng)立了自己的咨詢公司。他公開(kāi)批評(píng)IBM的DB2沒(méi)有完全遵循關(guān)系模型，尤其不滿SQL對(duì)關(guān)系代數(shù)的"不忠實(shí)實(shí)現(xiàn)"。他主張用更純粹的查詢語(yǔ)言，甚至自己設(shè)計(jì)了一套"Codd's Relational Algebra"想推成標(biāo)準(zhǔn)。

市場(chǎng)沒(méi)理他。SQL已經(jīng)贏了。

2003年，Codd去世。他的論文被引用了超過(guò)4000次，但最諷刺的注腳可能是：今天程序員寫(xiě)SQL時(shí)，幾乎沒(méi)人讀過(guò)那12頁(yè)原文。關(guān)系模型太成功了，成功到變成了空氣——你呼吸它，卻看不見(jiàn)它。

2024年，當(dāng)大模型開(kāi)始用自然語(yǔ)言生成SQL，向量檢索和關(guān)系查詢?cè)谝粡埍砝锕泊?，Codd的表格抽象還能撐多久？PostgreSQL 16加了JSON性能的向量?jī)?yōu)化，MySQL 8.0支持窗口函數(shù)和CTE——關(guān)系數(shù)據(jù)庫(kù)在吞噬新特性，但也在被新場(chǎng)景重新定義邊界。

如果Codd今天復(fù)活，看到有人用他的模型存大模型生成的嵌入向量，再用SQL做近似最近鄰搜索，他會(huì)覺(jué)得這是理論的勝利，還是異端？