數據庫設計指南（三）：觸發器慎用、版本機制、字段命名與索引策略深度解析

觸發器：雙刃劍，慎用且文檔化

觸發器功能多可由其他方式替代，且調試時易成干擾源。若業務必須使用，請集中文檔化管理，避免隱性邏輯散落各處。

22. 內建版本機制：演進的基石

需求必變，結構必改。與其通過檢查新欄位/索引反推版本，不如在資料庫中顯式存儲版本資訊（如版本表或擴充屬性），一查即知，維護無憂。

23. 文本字段預留空間：避免未來重構之痛

ID 類字段（客戶編號、訂單號）長度應超出當前需求 2-3 位。以 10 位客戶 ID 為例，定義為 12-13 字符。空間成本極低：百萬筆資料僅增 3MB，卻能避免日後擴充導致的全庫重構風險。

24. 統一前綴命名法：SQL 簡潔度的隱形助推器

為各表欄位定義專屬前綴（如 Customer 表用 cu_，Order 表用 or_），查詢時無需重複表名：

-- 有前綴：清爽直觀
SELECT * FROM Customer, Order
WHERE cu_surname = 'MYNAME'
  AND cu_name_id = or_cust_name_id
  AND or_quantity = 1;

-- 無前綴：冗長易錯
SELECT * FROM Customer, Order
WHERE Customer.surname = 'MYNAME'
  AND Customer.name_id = Order.cust_name_id
  AND Order.quantity = 1;

雖可能干擾自動連接工具，但多表聯查時可讀性與維護性提升顯著。

第 3 部分：鍵與索引選擇策略

1. 數據採掘需預謀：索引服務於查詢模式

早期為追求極致正規化而精簡主索引，導致特定業務查詢既慢又不準。重建索引並合併關鍵字段後效能質變。關鍵洞察：主索引字段應服務於最高頻、最高價值的檢索路徑，而非盲目追求最小化。ODS（營運數據存儲）與 DW（數據倉庫）索引策略迥異：DW 需結合業務組織模式（如銷售區域劃分）設計，由領域專家與 DBA 共同權衡效能與正確性。

2. 系統生成主鍵：掌控索引完整性的金鑰

全面採用 Identity/Sequence 等系統生成鍵作為主鍵，可確保：

• 索引完整性由資料庫引擎而非人工把控
• 每行資料擁有穩定、唯一、不可變的標識
• 鍵結構一致性使邏輯缺陷易於發現

3. 字段分解服務索引：拆解 LIKE 查詢的效能陷阱

案例：case_number 含年份、流水號、類型、被告代碼，導致報表頻繁使用 LIKE '%2023%' 全表掃描。將其拆解為獨立索引欄位（year、serial、type、defendant_code），同樣報表速度提升數量級。原則：凡涉及模糊匹配的業務字段，拆解為獨立索引列。

4. 鍵設計四鐵律

1. 關聯字段必建外鍵
2. 所有鍵必須唯一
3. 避免複合鍵（單鍵更簡潔高效）
4. 外鍵必關聯唯一鍵列

5. 索引：數據檢索的最高效路徑

不再贅述，唯記：缺索引必慢，濫索引亦累——以查詢負載為導向，精準佈局。