Rust 應把 enum 當成資料庫一等公民

32/2026 顯示，Rust 團隊正在重建資料庫型別，因為傳統 SQL 仍缺少真正的 enum 模型。

我主張：Rust 應把 enum 視為資料庫的一等公民，而不是把它當成應用層的補丁。當資料一旦超出平面欄位與字串，資料庫就成了整個型別故事裡最弱的一環。近期論壇裡，一位正在做資料庫軟體的開發者已經直接規劃 tuples、structs、enums、lists、maps、sets，這不是炫技，而是現實需求。

第一個論點：SQL 的型別模型太薄，撐不住現代應用資料

第一個理由很直接：現代應用資料早就不是單純的 scalar columns，但 SQL 的遺產型設計仍逼人把一切壓扁。那位資料庫作者提出的不是抽象理想，而是要把 Rust 的真實資料形狀保留下來。只要資料有巢狀結構、帶標籤的聯合型別、或集合，開發者就得回頭用 join table、JSON blob，或自訂編碼規則硬湊。

這不是品味問題，是正確性問題。Rust enum 可以精準描述狀態分支與不同 payload；SQL 的 enum 多半只是受限字串。兩者差距很大，因為資料庫本來就應該承載不變式。如果儲存層無法清楚表達領域模型，每個讀取它的服務都得重寫驗證邏輯，migration 也會變成一次賭博。

第二個論點：Rust 會持續把儲存層推向更豐富的 primitive

第二個理由是 Rust 生態正在把壓力往資料庫端推。Rust 開發者習慣讓型別系統延伸到編譯器之外，直到 persistence 也能保有同樣的嚴格度。論壇裡那位資料庫作者不是孤例；另有參與者談到把 spectrogram pipeline 搬到 GPU，並以 Vulkan、slang、ring buffers 朝商用推進。這類系統工作依賴精準資料布局與可預測轉換，資料庫若還只提供原始欄位與臨時序列化，就跟不上。

更現實的是，Rust 讓非法狀態難以在記憶體中出現，開發者不會想在持久化邊界把這個好處丟掉。若服務在程式內用 struct、enum、Option 建模，到了資料庫卻被迫繞回字串或 JSON，錯誤就會在邊界上反覆出現。這會形成一種分裂架構：Rust 程式很嚴謹，資料庫卻很寬鬆。順序反了，儲存層才應該是整條堆疊最嚴格的地方。

反方可能怎麼說

最強的反對意見是：SQL 的簡單正是它的力量。關聯式資料庫之所以能活這麼久，是因為它們偏向可攜性、成熟工具鏈與可預測的查詢規劃，而不是追求豐富值型別。對很多系統來說，基本的 enum 欄位已經夠用；更複雜的情況可以用正規化表或 JSON 處理。從這個角度看，要求資料庫理解 Rust 式 enum，像是把程式語言的型別代數硬塞進儲存系統。

這個批評有一半是對的。不是每個 schema 都需要帶 payload 的 variant，也不是每個團隊都想承擔更表達性的儲存引擎成本。但反駁也很清楚：現有替代方案並沒有消除複雜度，只是把它藏進應用程式、migration、序列化層。若領域本來就有結構化的 variants，把它編成字串或 JSON 不會讓系統更簡單，只會讓資料庫失去替你守住不變式的能力。

你能做什麼

如果你是工程師、PM 或創辦人，正在做 Rust-backed 系統，別再把 rich data types 當成純應用層問題。先把領域模型畫清楚，再選能保留這個模型、不必扁平化的儲存方案。優先使用明確的 schema 邊界，挑選能自然表達結構化值的資料庫或 extension，拒絕把 enums、tuples、巢狀 records 全塞進 stringly typed 欄位。目標不是讓 SQL 長得像 Rust，而是讓不變式從記憶體一路活到磁碟。