數據庫設計指南（二）：變更追蹤、命名藝術、標準化權衡與角色實體模式

1. 變更即常態：為數據演進預留軌道

姓名、地址、職稱等業務屬性皆可能隨時間變更。採用「屬性表 + 生效日/失效日」模式獨立存儲，而非直接覆寫主表，可完整保留歷史軌跡，支援時間點查詢與審計追溯。

2. 命名：給未來的自己留條清晰路

避免匈牙利符號（cbo1、txt2_b）或螢幕標籤式命名。追求「自描述性」與「輸入效率」平衡：Customer_Shipping_Address_Street_Line_1 雖詳盡但極難輸入，CustShipAddr1 或 ShippingStreet1 更務實。原則：業務語義清晰、團隊共識一致、長度可控（≤30字符）。

3. 前綴消除歧義：同名不同表的分辨鑰

多表共存同義欄位（如 FirstName）時，表級前綴（CusFirstName、EmpFirstName）可瞬間定位來源。時效性數據必加 LastUpdatedDateTime，服務於問題排查、按日重處理、舊數據清理三大場景。

4. 標準化與數據驅動：靈活架構的雙引擎

• 外部連接資訊化：文件路徑、XML Schema、異構數據庫連接串存入 UI 支援表，而非硬編碼
• 工作流數據化：郵件模板、列印規則、狀態機轉移條件入庫，業務調整僅需改數據不改代碼
• 責任前移：數據驅動意味著業務用戶可自維護流程，IT 從「改代碼」轉為「管平台」

5. 標準化止於 3NF：務實勝過教條

3NF（第三範式）在效能、擴展性、完整性間達到最佳平衡：

• 值唯一表達
• 行唯一標識
• 非鍵不依賴非鍵

典型 3NF 模式：Customer、Order 兩表，訂單表僅存客戶鍵值。但更高範式（BCNF、4NF、5NF）往往引入過度連接，拖垮效能。真實案例：財務分析系統通過反正規化將查詢從 40 秒壓至 2 秒。反正規化是派生物，而非設計本源——出問題可隨時從標準化模型重建，風險可控。

6. Access 報表小技巧：友好名稱勝過技術代碼

使用 Customer Name 替代 txtCNaM，嚮導生成的表單/報表即可被非技術人員直接閱讀理解。

7. 非活躍標記：軟刪除的優雅替代

增設 IsActive / InactiveDate 欄位，查詢時過濾而非物理刪除。效益三重：保留歷史關聯、防誤用舊數據、新用戶不見臟數據。

8. 角色實體模式：動態分類的終極解法

拒絕在 Person 表加 Title 欄位。改建 Person_Type 實體，Person 與 Person_Type 以鍵值關聯並附帶生效時間。晉升路徑：Engineer → Director → CIO 僅需更新關聯鍵 + 記錄時間。Person_Type 表天然成為全組織人員分類字典，自帶文檔屬性。