第 3 部分 - 選擇鍵和索引
數據采掘要預先計劃
我所在的某一客戶部門一度要處理 8 萬多份聯系方式，同時填寫每個客戶的必要數據（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數據庫的運行速度。然后我意識到特定的組查詢和信息采掘既不準確速度也不快。結果只好在主索引中重建而且合并了數據字段。我發現有一個指示計劃相當關鍵——當我想創建系統類型查找時為什么要采用號碼作為主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統類型一樣對我來說并不重要。采用后者作為主字段，數據庫更新后重新索引和檢索就快多了。
可操作數據倉庫（ODS）和數據倉庫（DW）這兩種環境下的數據索引是有差別的。在 DW 環境下，你要考慮銷售部門是如何組織銷售活動的。他們并不是數據庫管理員，但是他們確定表內的鍵信息。這里設計人員或者數據庫工作人員應該分析數據庫結構從而確定出性能和正確輸出之間的最佳條件。
使用系統生成的主鍵
這類同技巧 1，但我覺得有必要在這里重復提醒大家。假如你總是在設計數據庫的時候采用系統生成的鍵作為主鍵，那么你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。
采用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。
分解字段用于索引
為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進行索引。索引將加快 SQL 和報表生成器腳本的執行速度。比方說，我通常在必須使用 SQL LIKE 表達式的情況下創建報表，因為 case number 字段無法分解為 year、serial number、case type 和 defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。
鍵設計 4 原則
1.為關聯字段創建外鍵。
2.所有的鍵都必須唯一。
3.避免使用復合鍵。
4.外鍵總是關聯唯一的鍵字段。