數據庫必須有主鍵嗎？一場LinkedIn論戰撕開了建模的哲學傷口

“實際觀察到的數據，可能根本就沒有關系模型所要求的自然鍵。數據域也不是能清晰定義的——我們甚至沒法就‘什么是國家’達成一致，也不知道該怎么妥善跟蹤人類語言，連編程語言的語義標準都鎖不死。更頭疼的是，立法常常禁止存儲能唯一標識一個人的任何鍵。至于規范化，它根本就是高速分析的死對頭——沒有哪個分析型系統會用它。”

這段話不是數據庫教科書的反面案例，而是真實流傳在LinkedIn上的一句吐槽。它直指關系模型的兩個根基：一切數據都必須有唯一標識（鍵），所有存儲都應該消除冗余（規范化）。發帖人得出結論：理論很美，但現實里到處是例外。

很快，名叫Eduardo Bellani的架構師跳了出來。他沒有糾結哪個數據庫引擎跑得更快，而是把扳手伸向了更底層：你確定你說的“沒有鍵”是真的沒有，還是你沒發現而已？

Bellani給出的定義簡單到近乎哲學：關系模型中的鍵，就是那個能讓一句斷言在話語域中被唯一指認的部分。比如“Bob的薪水是100”，這句話里的“Bob”就是一種鍵：它劃定了這句話說的是誰。只要你承認自己有辦法存儲Bob的薪水，你就已經承認有辦法唯一指向Bob。所以，不是數據沒有自然鍵，而是任何能被人存進系統的數據，都必定已經帶著某種鍵——哪怕這個鍵只在應用程序的內存里存活了幾微秒。

原始帖子里那條“找不到國家的主鍵”的抱怨，恰好撞上了同一個邏輯。國家作為一個概念確實邊界模糊，但只要你試圖在系統里寫入一條與國家有關的記錄——比如稅率、首都、官方語言——你就在那一刻固定了這句斷言指的是哪個實體。“國家”此時已經擁有了足以在對應話語域里被唯一識別的鍵。討論現實世界的復雜性，不等于否定鍵的存在，只是承認發現鍵的代價很大。

順著同樣的拆解，Bellani把矛頭轉向了立法困局。如果法律禁止存儲個人身份證號、手機號甚至姓名，是不是鍵就被法律殺死了？他的回答堪稱鋒利：立法改變的不是“有沒有鍵”，而是整個謂詞被迫改變。以前“用戶X的年齡是Y”是一個可記錄的謂詞，現在法律強制你只能記錄“某地區30歲以上用戶數的總和”——謂詞變了，鍵也隨之改變，但“必須有鍵”的要求沒有消失。限制存儲內容，從來不會讓關系模型破產，只是讓開發者重新設計一句仍能承載唯一性的斷言而已。

這三層回應，每一層都在重復同一個信號：鍵不是關系模型的緊箍咒，而是任何有意義的數據敘事的骨架。你沒法表達一個想法而同時完全不指向它，也沒法在系統里保存一句事實而不給它掛上一個能反復找回的把手。

最容易被誤傷的受害者可能是“規范化”。原始帖子把分析系統繞著規范化走的現象解讀為“規范化天生慢”。但規范化究竟在做什么？它只是要求一個經過編碼的關系只對應一個邏輯謂詞。換句話說，一張表只說一件事，不把顧客信息、訂單金額和物流狀態煮成一鍋粥。這原則上和性能毫無必然聯系。

那我們明明看到高度規范化的系統有時跑得氣喘吁吁，又是怎么回事？答案在別處：是為了查詢方便而刻意引入的冗余結構，是因為索引策略、存儲引擎、計算資源分配沒能跟上語義模型的簡潔。規范化本身沒有把數據打入慢速地獄，是人自己選擇在規范化的純凈地基上疊加了一層又一層的性能折衷。原始帖子里那個“沒有分析系統用規范化”的觀察，充其量只說明了工程實現的現實，卻證明不了規范化的設計原罪。

Bellani的最終一擊，把話題從數據庫拉進了本體論。鍵和規范化的必要性，并不是某個模型在40年前的心血來潮。它折射的是我們試圖建模的那個世界本身的特性。你必須能唯一地指稱事物，而為了做到這點，事物就必須擁有穩定、能相互區分的“本質”。

“什么是國家”很難定義，不代表國家的本質不存在，只代表我們發現本質的過程磕磕絆絆。這是認識論上的困難，而不是本體論上的缺失。同樣，在系統里到底用UUID還是業務主鍵，到底拆成幾張表，表面上是技術選型，底層卻是一句追問：我們想要言說的那個世界，究竟由哪些不可再混淆的東西構成？

關系模型沒有把人工秩序強加給無形式的數據，它只是把一切連貫話語都預先預設的一件事挑明了：世界是充滿了具有本質的事物的。任何一個系統，只要它還想忠實地反映現實、真正幫人做事，就繞不開對這層本質的發現與尊重。那場LinkedIn上的爭論，與其說是數據庫原理的攻防，不如說是給所有工程師轉播了一期哲學課：你每建一次表、每選一次主鍵，都在替你要解決的問題回答一個深不見底的問題——這個玩意到底是什么？