E.F Codd提出的12條準則

第 3 部分 - 選擇鍵和索引
數據採掘要預先計劃
我所在的某一客戶部門一度要處理 8 萬多份聯繫方式，同時填寫每個客戶的必要數據（這絕對不是小活）。我從中還要確定出一組客戶作爲市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裏增加太多的字段以便加快數據庫的運行速度。然後我意識到特定的組查詢和信息採掘既不準確速度也不快。結果只好在主索引中重建而且合併了數據字段。我發現有一個指示計劃相當關鍵--當我想創建系統類型查找時爲什麼要採用號碼作爲主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統類型一樣對我來說並不重要。採用後者作爲主字段，數據庫更新後重新索引和檢索就快多了。

可操作數據倉庫（ODS）和數據倉庫（DW）這兩種環境下的數據索引是有差別的。在 DW 環境下，你要考慮銷售部門是如何組織銷售活動的。他們並不是數據庫管理員，但是他們確定表內的鍵信息。這裏設計人員或者數據庫工作人員應該分析數據庫結構從而確定出性能和正確輸出之間的最佳條件。 
使用系統生成的主鍵
這類同技巧 1，但我覺得有必要在這裏重複提醒大家。假如你總是在設計數據庫的時候採用系統生成的鍵作爲主鍵，那麼你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。
採用系統生成鍵作爲主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。 
分解字段用於索引
爲了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）爲其組成要素以便用戶可以對其進行索引。索引將加快 SQL 和報表生成器腳本的執行速度。比方說，我通常在必須使用 SQL LIKE 表達式的情況下創建報表，因爲 case number 字段無法分解爲 year、serial number、case type 和 defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解爲索引字段那麼這些報表運行起來就會快多了。 
鍵設計 4 原則
* 爲關聯字段創建外鍵。
* 所有的鍵都必須唯一。
* 避免使用複合鍵。
* 外鍵總是關聯唯一的鍵字段。 
別忘了索引
索引是從數據庫中獲取數據的最高效方式之一。95% 的數據庫性能問題都可以採用索引技術得到解決。作爲一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作爲存儲過程）採用唯一的非成組索引，對任何外鍵列[字段]採用非成組索引。不過，索引就象是鹽，太多了菜就鹹了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。

大多數數據庫都索引自動創建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引佔用太多的存儲空間。 
不要索引常用的小型表
不要爲小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。 
不要把社會保障號碼（SSN）或身份證號碼（ID）選作鍵
永遠都不要使用 SSN 或 ID 作爲數據庫的鍵。除了隱私原因以外，須知政府越來越趨向於不准許把 SSN 或 ID 用作除收入相關以外的其他目的，SSN 或 ID 需要手工輸入。永遠不要使用手工輸入的鍵作爲主鍵，因爲一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然後從頭開始。

我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當然儘管這麼做是非法的。而且人們也都知道這是非法的，但他們已經習慣了。後來，隨着盜取身份犯罪案件的增加，我現在的同行正痛苦地從一大攤子數據中把 SSN 或 ID 刪除。 
不要用用戶的鍵
在確定採用什麼字段作爲表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作爲鍵。這樣做會迫使你採取以下兩個措施：
* 在創建記錄之後對用戶編輯字段的行爲施加限制。假如你這麼做了，你可能會發現你的應用程序在商務需求突然發生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當用戶在輸入數據之後直到保存記錄才發現系統出了問題他們該怎麼想？刪除重建？假如記錄不可重建是否讓用戶走開？
* 提出一些檢測和糾正鍵衝突的方法。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的數據和商業/用戶界面層之間的隔離。
所以還是重提一句老話：你的設計要適應用戶而不是讓用戶來適應你的設計。

不讓主鍵具有可更新性的原因是在關係模式下，主鍵實現了不同表之間的關聯。比如，Customer 表有一個主鍵 CustomerID，而客戶的定單則存放在另一個表裏。Order 表的主鍵可能是 OrderNo 或者 OrderNo、CustomerID 和日期的組合。不管你選擇哪種鍵設置，你都需要在 Order 表中存放 CustomerID 來保證你可以給下定單的用戶找到其定單記錄。
假如你在 Customer 表裏修改了 CustomerID，那麼你必須找出 Order 表中的所有相關記錄對其進行修改。否則，有些定單就會不屬於任何客戶--數據庫的完整性就算完蛋了。
如果索引完整性規則施加到表一級，那麼在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數據庫內所有關聯的記錄。而這一過程往往錯誤叢生所以應該儘量避免。 
可選鍵(候選鍵)有時可做主鍵
記住，查詢數據的不是機器而是人。
假如你有可選鍵，你可能進一步把它用做主鍵。那樣的話，你就擁有了建立強大索引的能力。這樣可以阻止使用數據庫的人不得不連接數據庫從而恰當的過濾數據。在嚴格控制域表的數據庫上，這種負載是比較醒目的。如果可選鍵真正有用，那就是達到了主鍵的水準。
我的看法是，假如你有可選鍵，比如國家表內的 state_code，你不要在現有不能變動的唯一鍵上創建後續的鍵。你要做的無非是創建毫無價值的數據。如你因爲過度使用表的後續鍵[別名]建立這種表的關聯，操作負載真得需要考慮一下了。 
別忘了外鍵
大多數數據庫索引自動創建的主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中的記錄及其關聯記錄時每次都會用到。還有，不要索引 memo/notes 字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引佔據大量的數據庫空間。 
第 4 部分 - 保證數據的完整性
用約束而非商務規則強制數據完整性
如果你按照商務規則來處理需求，那麼你應當檢查商務層次/用戶界面：如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護數據完整性的需要，那麼在數據庫層面上需要施加限制條件。如果你在數據層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，否則字段名本身還不夠。

只要有可能，請採用數據庫系統實現數據的完整性。這不但包括通過標準化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。 
分佈式數據系統
對分佈式系統而言，在你決定是否在各個站點複製所有數據還是把數據保存在一個地方之前應該估計一下未來 5 年或者 10 年的數據量。當你把數據傳送到其他站點的時候，最好在數據庫字段中設置一些標記。在目的站點收到你的數據之後更新你的標記。爲了進行這種數據傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝你的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全一致。 
強制指示完整性(參照完整性?)
沒有好辦法能在有害數據進入數據庫之後消除它，所以你應該在它進入數據庫之前將其剔除。激活數據庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。 
關係
如果兩個實體之間存在多對一關係，而且還有可能轉化爲多對多關係，那麼你最好一開始就設置成多對多關係。從現有的多對一關係轉變爲多對多關係比一開始就是多對多關係要難得多。 
採用視圖
爲了在你的數據庫和你的應用程序代碼之間提供另一層抽象，你可以爲你的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理數據庫變更時給你提供了更多的自由。 
給數據保有和恢復制定計劃
考慮數據保有策略幷包含在設計過程中，預先設計你的數據恢復過程。採用可以發佈給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來"更新查詢"供以後萬一數據丟失可以重新處理更新。 
用存儲過程讓系統做重活
解決了許多麻煩來產生一個具有高度完整性的數據庫解決方案之後，我決定封裝一些關聯表的功能組，提供一整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。數據庫不只是一個存放數據的地方，它也是簡化編碼之地。 
使用查找
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找：國家代碼、狀態代碼等。 
第 5 部分 - 各種小技巧
文檔、文檔、文檔
對所有的快捷方式、命名規範、限制和函數都要編制文檔。

採用給表、列[字段]、觸發器等加註釋的數據庫工具。是的，這有點費事，但從長遠來看，這樣做對開發、支持和跟蹤修改非常有用。

取決於你使用的數據庫系統，可能有一些軟件會給你一些供你很快上手的文檔。你可能希望先開始在說，然後獲得越來越多的細節。或者你可能希望週期性的預排，在輸入新數據同時隨着你的進展對每一部分細節化。不管你選擇哪種方式，總要對你的數據庫文檔化，或者在數據庫自身的內部或者單獨建立文檔。這樣，當你過了一年多時間後再回過頭來做第 2 個版本，你犯錯的機會將大大減少。 
使用常用英語（或者其他任何語言）而不要使用編碼
爲什麼我們經常採用編碼（比如 9935A 可能是'青島啤酒'的供應代碼，4XF788-Q 可能是帳目編碼）？理由很多。但是用戶通常都用英語進行思考而不是編碼。工作 5 年的會計或許知道 4XF788-Q 是什麼東西，但新來的可就不一定了。在創建下拉菜單、列表、報表時最好按照英語名排序。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。 
保存常用信息
讓一個表專門存放一般數據庫信息非常有用。我常在這個表裏存放數據庫當前版本、最近檢查/修復（對 FoxPro）、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤數據庫，當客戶抱怨他們的數據庫沒有達到希望的要求而與你聯繫時，這樣做對非客戶機/服務器環境特別有用。 
測試、測試、反覆測試
建立或者修訂數據庫之後，必須用用戶新輸入的數據測試數據字段。最重要的是，讓用戶進行測試並且同用戶一道保證你選擇的數據類型滿足商業要求。測試需要在把新數據庫投入實際服務之前完成。 
檢查設計
在開發期間檢查數據庫設計的常用技術是通過其所支持的應用程序原型檢查數據庫。換句話說，針對每一種最終表達數據的原型應用，保證你檢查了數據模型並且查看如何取出數據。