觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要采用觸發器，你最好集中對它文檔化。
22. 包含版本機制建議你在數據庫中引入版本控制機制來確定使用中的數據庫的版本。無論如何你都要實現這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數據庫結構。雖然你可以通過檢查新字段或者索引來確定數據庫結構的版本，但我發現把版本信息直接存放到數據庫中不更為方便嗎？。
23. 給文本字段留足余量ID 類型的文本字段，比如客戶ID 或定單號等等都應該設置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設你的客戶ID 為10 位數長。那你應該把數據庫表字段的長度設為12 或者13 個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那麼多：一個字段加長3 個字符在有1 百萬條記錄，再加上一點索引的情況下才不過讓整個數據庫多占據3MB 的空間。但這額外占據的空間卻無需將來重構整個數據庫就可以實現數據庫規模的增長了。
24. 列命名技巧我們發現，假如你給每個表的列名都采用統一的前綴，那麼在編寫SQL 表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，後者把公共列名同某些數據庫聯系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設有兩個表：
Customer 和Order。Customer 表的前綴是cu_，所以該表內的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是or_，所以子段名是：or_order_id、or_cust_name_id、or_quantity 和or_description 等。
這樣從數據庫中選出全部數據的SQL 語句可以寫成如下所示：
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
第1 個SQL 語句沒少鍵入多少字符。但如果查詢涉及到5 個表乃至更多的列你就知道這個技巧多有用了。
第3 部分— 選擇鍵和索引1. 數據采掘要預先計劃我所在的市場部門一度要處理8 萬多份聯系方式，同時填寫每個客戶的必要數據（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快數據庫的運行速度。然後我意識到特定的組查詢和信息采掘既不准確速度也不快。結果只好在主索引中重建而且合並了數據字段。我發現有一個指示計劃相當關鍵——當我想創建系統類型查找時為什麼要采用號碼作為主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統類型一樣對我來說並不重要。采用後者作為主字段，數據庫更新後重新索引和檢索就快多了。
可操作數據倉庫（ODS）和數據倉庫（DW）這兩種環境下的數據索引是有差別的。在DW 環境下，你要考慮銷售部門是如何組織銷售活動的。他們並不是數據庫管理員，但是他們確定表內的鍵信息。這裡設計人員或者數據庫工作人員應該分析數據庫結構從而確定出性能和正確輸出之間的最佳條件。
2. 使用系統生成的主鍵這一天類同技巧1，但我覺得有必要在這裡重復提醒大家。假如你總是在設計數據庫的時候采用系統生成的鍵作為主鍵，那麼你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。
采用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。
3. 分解字段用於索引為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進行索引。索引將加快SQL 和報表生成器腳本的執行速度。比方說，我通常在必須使用SQL LIKE 表達式的情況下創建報表，因為case number 字段無法分解為year、serial number、case type 和defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那麼這些報表運行起來就會快多了。
4. 鍵設計4 原則· 為關聯字段創建外鍵。
· 所有的鍵都必須唯一。
· 避免使用復合鍵。
· 外鍵總是關聯唯一的鍵字段。
5. 別忘了索引索引是從數據庫中獲取數據的最高效方式之一。
