從例外狀況與未來擴充談起

在設計資料庫的過程中，我們通常會遵循一系列規則與最佳實務，例如資料正規化、資料型別設計與欄位約束。然而，在這些「規則」背後，例外情況往往是資料模型崩壞的根源。忽略這些例外可能會導致日後重構資料庫的成本大增。因此，我們在資料庫設計初期，就應該主動「挑戰規則」，深入了解業務邏輯中潛藏的變異與潛在擴展。

一個危險的詞：通常（Usually）

當有人說「某個欄位通常只會有一個值」時，這是一個設計的警訊。這個「通常」很可能會在某天失效，進而影響整個資料結構。請務必釐清：「這是業務邏輯上的絕對條件，還是只是一個暫時的觀察？」
假設你正在設計一個記錄使用者聯絡方式的系統，有人說：

「一個使用者通常只會有一個手機號碼，所以我們直接在 users 表加一個 phone_number 欄位就好了。」

萬一未來需求變更，例如：使用者可以登記多支手機，或加入家人共用帳號，每個人都有不同手機，這時原本一個欄位的設計就無法擴展，非得：

• 修改資料表結構（大工程）
• 或改成用逗號分隔的欄位（違反正規化，查詢困難）

為未來擴充做準備

好的資料庫設計不只解決當下問題，也應預見未來可能的成長與改變。例如：

• 客戶編號與欄位長度
  假設你設計的客戶編號欄位是 4 位數，從 0000 到 9999，但當業務擴展，客戶數突破 10000 時，原本的設計將無法支撐。這類問題本質上是對「最大值」估計不足所導致，應避免將系統限制死在一個過窄的範圍中。
• Y2K 問題的借鏡
  2000年初爆發的 Y2K 危機，就是因為許多系統只用「兩位數」來儲存年份。例如，1999 年會被儲存為 99，而 2000 年則成為 00。這導致系統無法正確判斷年份，甚至將 2000 年誤解為 1900 年。這類問題本可透過更周延的設計（如儲存完整四位數年份）避免。

資料型別與欄位限制應審慎設計

每個欄位的資料型別與限制都應在充分了解業務邏輯後設計，例如：
像「產品價格」這種欄位，若系統強制保留兩位小數，那麼就應該驗證是否有實際需求可能產生三位小數。
若無業務上的絕對需求，則不應過早設限，避免未來難以擴充。

總結

資料庫的生命週期通常很長。設計得當的資料模型可以經年不變地支撐系統演進。要做到這一點，就必須在設計初期：

• 主動探索業務規則的例外情況
• 質疑任何以「通常」為前提的假設
• 預留足夠彈性以因應未來變化

一句話總結：「設計時多問幾個為什麼，勝過事後大動幹戈的重構。」