資料庫設計經驗談(上)
乙個成功的管理系統，是由：[50% 的業務 + 50% 的軟體] 所組成，而 50% 的成功軟體又有 [25% 的資料庫 + 25% 的程式] 所組成，資料庫設計的好壞是乙個關鍵。如果把企業的資料比做生命所必需的血液，那麼資料庫的設計就是應用中最重要的一部分。有關資料庫設計的材料汗牛充棟，大學學位課程裡也有專門的講述。不過，就如我們反覆強調的那樣，再好的老師也比不過經驗的教誨。所以我歸納歷年來所走的彎路及體會，並在網上找了些對資料庫設計頗有造詣的專業人士給大家傳授一些設計資料庫的技巧和經驗。精選了其中的 60 個最佳技巧，並把這些技巧編寫成了本文，為了方便索引其內容劃分為 5 個部分：
第 1 部分 - 設計資料庫之前
這一部分羅列了 12 個基本技巧，包括命名規範和明確業務需求等。
第 2 部分 - 設計資料庫表
總共 24 個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等。
第 3 部分 - 選擇鍵
怎麼選擇鍵呢？這裡有 10 個技巧專門涉及系統生成的主鍵的正確用法，還有何 時以及如何索引欄位以獲得最佳效能等。
第 4 部分 - 保證資料完整性
討論如何保持資料庫的清晰和健壯，如何把有害資料降低到最小程度。
第 5 部分 - 各種小技巧
不包括在以上 4 個部分中的其他技巧，五花八門，有了它們希望你的資料庫開發工作會更輕鬆一些。
第 1 部分 - 設計資料庫之前
考察現有環境
在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫專案都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
定義標準的物件命名規範
一定要定義資料庫物件的命名規範。對資料庫表來說，從專案一開始就要確定表名是採用複數還是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是乙個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取乙個然後從最後乙個單詞中再取出兩個字母，結果還是組成 4 字母長的別名，其餘依次類推）對工作用表來說，表名可以加上字首 work_ 後面附上採用該錶的應用程式的名字。表內的列[字段]要針對鍵採用一整套設計規則。比如，如果鍵是數字型別，你可以用 _n 作為字尾；如果是字元型別則可以採用 _c 字尾。對列[字段]名應該採用標準的字首和字尾。再如，假如你的表裡有好多「money」字段，你不妨給每個列[字段]增加乙個 _m 字尾。還有，日期列[字段]最好以 d_ 作為名字打頭。
檢查表名、報表名和查詢名之間的命名規範。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。假如你堅持統一地命名這些資料庫的不同組成部分，至少你應該在這些物件名字的開頭用 table、query 或者 report 等字首加以區別。
如果採用了 microsoft access，你可以用 qry、rpt、tbl 和 mod 等符號來標識物件（比如 tbl_employees）。我在和 sql server 打交道的時候還用過 tbl 來索引表，但我用 sp_company （現在用 sp_feft_）標識儲存過程，因為在有的時候如果我發現了更好的處理辦法往往會儲存好幾個拷貝。我在實現 sql server 2000 時用 udf_ （或者類似的標記）標識我編寫的函式。
工欲善其事, 必先利其器
採用理想的資料庫設計工具，比如：sybase 公司的 powerdesign，她支援 pb、vb、delphe 等語言，通過 odbc 可以連線市面上流行的 30 多個資料庫，包括 dbase、foxpro、vfp、sql server 等，今後有機會我將著重介紹 powerdesign 的使用。
獲取資料模式資源手冊
正在尋求示例模式的人可以閱讀《資料模式資源手冊》一書，該書由 len silverston、w. h. inmon 和 kent graziano 編寫，是一本值得擁有的最佳資料建模圖書。該書包括的章節涵蓋多種資料領域，比如人員、機構和工作效能等。其他的你還可以參考：[1]薩師煊 王珊著 資料庫系統概論(第二版)高等教育出版社 1991、[2][美] steven m.bobrowski 著 oracle 7 與客戶／伺服器計算技術從入門到精通 劉建元等譯 電子工業出版社，1996、[3]週中元 資訊系統建模方法(下) 電子與資訊化 2023年第3期，1999
暢想未來，但不可忘了過去的教訓
我發現詢問使用者如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免效能瓶頸；其次，你知道發生事先沒有確定的需求變更時使用者將和你一樣感到吃驚。
一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使使用者認為他們再也不需要什麼支援了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻「當初要是這麼做了該多好..」。
在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 case 工具不斷湧現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。
了解你的業務
在你百分百地確定系統從客戶角度滿足其需求之前不要在你的 er（實體關係）模式中加入哪怕乙個資料表（怎麼，你還沒有模式？那請你參看技巧 9）。了解你的企業業務可以在以後的開發階段節約大量的時間。一旦你明確了業務需求，你就可以自己做出許多決策了。
一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。採用客戶的術語並且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞彙表達出系統的關係基數。這樣你就可以讓你的客戶糾正你自己的理解然後做好下一步的 er 設計。
建立資料字典和 er 圖表
一定要花點時間建立 er 圖表和資料字典。其中至少應該包含每個欄位的資料型別和在每個表內的主外來鍵。建立 er 圖表和資料字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早建立越能有助於避免今後面臨的可能混亂，從而可以讓任何了解資料庫的人都明確如何從資料庫中獲得資料。
時效性資料應包括「最近更新日期/時間」字段。時間標記對查詢資料問題的原因、按日期重新處理/過載資料和清除舊資料特別有用。
標準化和資料驅動
資料的標準化不僅方便了自己而且也方便了其他人。比方說，假如你的使用者介面要訪問外部資料來源（檔案、xml 文件、其他資料庫等），你不妨把相應的連線和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流之類的任務（傳送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的資料也可以存放在資料庫裡。預先安排總需要付出努力，但如果這些過程採用資料驅動而非硬編碼的方式，那麼策略變更和維護都會方便得多。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流過程。
標準化不能過頭
對那些不熟悉標準化一詞（normalization）的人而言，標準化可以保證表內的字段都是最基礎的要素，而這一措施有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但 third normal form（3nf）通常被認為在效能、擴充套件性和資料完整性方面達到了最好平衡。簡單來說，3nf 規定：
* 表內的每乙個值都只能被表達一次。
* 表內的每一行都應該被唯一的標識（有唯一鍵）。
* 表內不應該儲存依賴於其他鍵的非鍵資訊。
遵守 3nf 標準的資料庫具有以下特點：有一組表專門存放通過鍵連線起來的關聯資料。比方說，某個存放客戶及其有關定單的 3nf 資料庫就可能有兩個表：customer 和 order。order 表不包含定單關聯客戶的任何資訊，但表內會存放乙個鍵值，該鍵指向 customer 表裡包含該客戶資訊的那一行。
更高層次的標準化也有，但更標準是否就一定更好呢？答案是不一定。事實上，對某些專案來說，甚至就連 3nf 都可能給資料庫引入太高的複雜性。
過分標準化可要小心，這樣做可能會導致效能上出現問題。雖然位址和**表分離通常可以達到最佳狀態，但是如果需要經常訪問這類資訊，或許在其父表中存放「首選」資訊（比如 customer 等）更為妥當些。非標準化和加速訪問之間的妥協是有一定意義的。
使用多個名稱字段
我覺得很吃驚，許多人在資料庫裡就給 name 留乙個字段。我覺得只有剛入門的開發人員才會這麼做，但實際上網上這種做法非常普遍。我建議應該把姓氏和名字當作兩個欄位來處理，然後在查詢的時候再把他們組合起來。
資料庫設計經驗談 下
資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...
資料庫設計經驗談 下
引用 http blog.csdn.net softj services trackbacks 497813.aspx 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從...
資料庫設計經驗談 4
第 4 部分 保證資料的完整性 如果你按照商務規則來處理需求，那麼你應當檢查商務層次 使用者介面 如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護資料完整性的需要，那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用使用者...