【正文】 轉載 推薦 數(shù)據(jù)庫設計經驗談 轉帖 原文地址： [推薦 ]數(shù)據(jù)庫設計經驗談 (轉帖 )作者： yinger 090807 來源：一個成功的管理系統(tǒng)，是由： [50%的業(yè)務 +50%的軟件 ]所組成， 而 50%的成功軟件又有 [25%的數(shù)據(jù)庫 +25%的程序 ]所組成，數(shù)據(jù)庫設計的好壞是一個關鍵。 如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設計就是應用中最重要的一部分。 有關數(shù)據(jù)庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。 不過，就如我們反復強調的那樣，再好的老師也比不過經驗的教誨。 所以我歸納歷年來所走的彎路及體會，并在網上找了些對數(shù)據(jù)庫設計頗有造詣的專業(yè)人士給大家傳授一些設計數(shù)據(jù)庫的技巧和經驗。 精選了其中的 60個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為 5個部分： 第 1部分 設計數(shù)據(jù)庫之前 這一部分羅列了 12個基本技巧，包括命名規(guī)范和明確業(yè)務需求等。 第 2部分 設計數(shù)據(jù)庫表 總共 24 個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等。 第 3部分 選擇鍵 怎么選擇鍵呢 ?這里有 10個技巧專門涉及系統(tǒng)生成的主鍵的正確用法，還有何時以及如何索引字段以獲得最佳性能等。 第 4部分 保證數(shù)據(jù)完整性 討論如何保持數(shù)據(jù)庫的清晰和健壯，如何把有害數(shù)據(jù)降低到最小程度。 第 5部分 各種小技巧 不包括在以上 4個部分中的其他技巧，五花八門，有了它們希望你的數(shù)據(jù)庫開發(fā)工作會更輕松一些。 第 1部分 設計數(shù)據(jù)庫之前 考察現(xiàn)有環(huán)境 在設計一個新數(shù)據(jù)庫時，你不但應該仔細研究業(yè)務需求而且還要考察現(xiàn)有的系統(tǒng)。大多數(shù)數(shù)據(jù)庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現(xiàn)有系統(tǒng) (可能沒有實現(xiàn)自動計算 )。顯然，現(xiàn)有系統(tǒng)并不完美，否則你就不必再建立新系統(tǒng)了。但是對舊系統(tǒng)的研究可以讓你發(fā)現(xiàn)一些可能會忽略的細微問題。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。 定義標準的對象命名規(guī)范 一定要定義數(shù)據(jù)庫對象的命名規(guī)范。對數(shù)據(jù)庫表來說，從項目一開始就要確定表名是采用復數(shù)還是單數(shù)形式。此外還要給表的別名定義簡單規(guī)則 (比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4個字母長的別名；如果表的名字由 3個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結果還是組成 4字母長的別名，其余依次類推 )對工作用表來說，表名可以加上前綴 WORK_后 面附上采用該表的應用程序的名字。表內的列 [字段 ]要針對鍵采用一整套設計規(guī)則。比如，如果鍵是數(shù)字類型，你可以用 _N作為后綴；如果是字符類型則可以采用 _C 后綴。對列 [字段 ]名應該采用標準的前綴和后綴。再如，假如你的表里有好多 money字段，你不妨給每個列 [字段 ]增加一個 _M 后綴。還有，日期列 [字段 ]最好以 D_作為名字打頭。 檢查表名、報表名和查詢名之間的命名規(guī)范。你可能會很快就被這些不同的數(shù)據(jù)庫要素的名稱搞糊涂了。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、 Query 或者 Report 等前綴加以區(qū)別。 如果采用了 Microsoft Access，你可以用 qry、 rpt、 tbl 和 mod 等符號來標識對象 (比如 tbl_Employees)。我在和 SQL Server 打交道的時候還用過 tbl來索引表，但我用 sp_pany(現(xiàn)在用 sp_feft_)標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。我在實現(xiàn) SQL Server 2021 時用 udf_(或者類似的標記 )標識我編寫的函數(shù)。 工欲善其事 ,必先利其器 采用理想的數(shù)據(jù)庫設計工具，比如： SyBase 公司的 PowerDesign，她支持PB、 VB、 Delphe 等語言，通過 ODBC可以連接市面上流行的 30 多個數(shù)據(jù)庫，包括 dBase、 FoxPro、 VFP、 SQL Server 等，今后有機會我將著重介紹PowerDesign 的使用。 獲取數(shù)據(jù)模式資源手冊 正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由 Len Silverston、 和 Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人 員、機構和工作效能等。 其他的你還可以參考：薩師煊王珊著數(shù)據(jù)庫系統(tǒng)概論 暢想未來，但不可忘了過去的教訓 我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。 一定要記住過去的經驗教訓！我們開發(fā)人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻 當初要是這么做了該多 好 .。 在物理實踐之前進行邏輯設計 在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現(xiàn)出來，你的設計也可以達到相當高的邏輯水準，你通?？梢詮恼w上更好地了解數(shù)據(jù)庫設計所需要的方方面面。 了解你的業(yè)務 在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER(實體關系 )模式中加入哪怕一個數(shù)據(jù)表 (怎么，你還沒有模式 ?那請你參看技巧 9)。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。 一旦你認為你已經明確了業(yè)務內容，你最好同客戶進行一次系 統(tǒng)的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數(shù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。 創(chuàng)建數(shù)據(jù)字典和 ER圖表 一定要花點時間創(chuàng)建 ER圖表和數(shù)據(jù)字典。其中至少應該包含每個字段的數(shù)據(jù)類型和在每個表內的主外鍵。創(chuàng)建 ER圖表和數(shù)據(jù)字典確實有點費時但對其他開發(fā)人員要了解整個設計卻是完全必要的。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。 有一份諸如 ER 圖表等最新文檔 其重要性如何強調都不過分，這對表明表之間關系很有用，而數(shù)據(jù)字典則說明了每個字段的用途以及任何可能存在的別名。對 SQL 表達式的文檔化來說這是完全必要的。 創(chuàng)建模式 一張圖表勝過千言萬語：開發(fā)人員不僅要閱讀和實現(xiàn)它，而且還要用它來幫助自己和用戶對話。模式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫設計中幾乎不可能出現(xiàn)大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今后能產生效益。 從輸入輸出下手 在定義數(shù)據(jù)庫表和字段需求 (輸入 )時，首先應檢查現(xiàn)有的或者已經設計出的報表、查詢 和視圖 (輸出 )以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。 報表技巧 要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表 ?時間間隔是每天、每周、每月、每個季度還是每年 ?如果需要的話還可以考慮創(chuàng)建總結表。系統(tǒng)生成的主鍵在報表中很難管理。用戶在具有系統(tǒng)生成主鍵的表內用副鍵進行檢索往往會返回許多重復數(shù)據(jù)。這樣的檢索性能比較低而且容易引起混亂。 理解客戶需求 看起來這應該是顯而易 見的事，但需求就是來自客戶 (這里要從內部和外部客戶的角度考慮 )。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經常詢問客戶保證其需求仍然在開發(fā)的目的之中。一個不變的真理是： 只有我看見了我才知道我想要的是什么 必然會導致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。 第 2部分 設計表和字段 檢查各種變化 我在設計數(shù)據(jù)庫的時候會考慮到哪些數(shù)據(jù)字段將來可能會發(fā)生變更。比方說，姓氏就是如此 (注意是西方人的姓氏，比如女性結婚后從夫姓等 )。所以，在建立系統(tǒng)存儲客戶信息時，我傾向于在單獨的一個數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。 采用有意義的字段名 有一回我參加開發(fā)過一個項目，其中有從其他程序員那里繼承的程序，那個程序員喜歡用屏幕上顯示數(shù)據(jù)指示用