一個成功的管理系統(tǒng)，是由：[50% 的業(yè)務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數(shù)據(jù)庫 + 25% 的程序] 所組成，數(shù)據(jù)庫設計的好壞是一個關鍵。如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設計就是應用中重要的一部分。有關數(shù)據(jù)庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。不過，就如我們反復強調(diào)的那樣，再好的老師也比不過經(jīng)驗的教誨。所以我歸納歷年來所走的彎路及體會，并在網(wǎng)上找了些對數(shù)據(jù)庫設計頗有造詣的專業(yè)人士給大家傳授一些設計數(shù)據(jù)庫的技巧和經(jīng)驗。精選了其中的 60 個佳技巧，并把這些技巧編寫成了本文，為了方便索引其內(nèi)容劃分為 5 個部分：
第 1 部分 - 設計數(shù)據(jù)庫之前
這一部分羅列了 12 個基本技巧，包括命名規(guī)范和明確業(yè)務需求等。
第 2 部分 - 設計數(shù)據(jù)庫表
總共 24 個指南性技巧，涵蓋表內(nèi)字段設計以及應該避免的常見問題等。
第 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ù)庫項目都不是從頭開始建立的；通常，機構(gòu)內(nèi)總會存在用來滿足特定需求的現(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 個單詞組成，你不妨從頭兩個單詞中各取一個然后從后一個單詞中再取出兩個字母，結(jié)果還是組成 4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴 WORK_ 后面附上采用該表的應用程序的名字。表內(nèi)的列[字段]要針對鍵采用一整套設計規(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_company （現(xiàn)在用 sp_feft_）標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。我在實現(xiàn) SQL Server 2000 時用 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、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構(gòu)和工作效能等。其他的你還可以參考：[1]薩師煊 王珊著 數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 與客戶／服務器計算技術從入門到精通 劉建元等譯 電子工業(yè)出版社，1996、[3]周中元 信息系統(tǒng)建模方法(下) 電子與信息化 1999年第3期，1999
暢想未來，但不可忘了過去的教訓
我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經(jīng)驗教訓！我們開發(fā)人員還應該通過分享自己的體會和經(jīng)驗互相幫助。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經(jīng)面臨過這樣的時刻“當初要是這么做了該多好..”。
在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現(xiàn)出來，你的設計也可以達到相當高的邏輯水準，你通?？梢詮恼w上更好地了解數(shù)據(jù)庫設計所需要的方方面面。
了解你的業(yè)務
在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個數(shù)據(jù)表（怎么，你還沒有模式？那請你參看技巧 9）。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。
一旦你認為你已經(jīng)明確了業(yè)務內(nèi)容，你好同客戶進行系統(tǒng)的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數(shù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。
第 1 部分 - 設計數(shù)據(jù)庫之前
這一部分羅列了 12 個基本技巧，包括命名規(guī)范和明確業(yè)務需求等。
第 2 部分 - 設計數(shù)據(jù)庫表
總共 24 個指南性技巧，涵蓋表內(nèi)字段設計以及應該避免的常見問題等。
第 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ù)庫項目都不是從頭開始建立的；通常，機構(gòu)內(nèi)總會存在用來滿足特定需求的現(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 個單詞組成，你不妨從頭兩個單詞中各取一個然后從后一個單詞中再取出兩個字母，結(jié)果還是組成 4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴 WORK_ 后面附上采用該表的應用程序的名字。表內(nèi)的列[字段]要針對鍵采用一整套設計規(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_company （現(xiàn)在用 sp_feft_）標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。我在實現(xiàn) SQL Server 2000 時用 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、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構(gòu)和工作效能等。其他的你還可以參考：[1]薩師煊 王珊著 數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 與客戶／服務器計算技術從入門到精通 劉建元等譯 電子工業(yè)出版社，1996、[3]周中元 信息系統(tǒng)建模方法(下) 電子與信息化 1999年第3期，1999
暢想未來，但不可忘了過去的教訓
我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經(jīng)驗教訓！我們開發(fā)人員還應該通過分享自己的體會和經(jīng)驗互相幫助。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經(jīng)面臨過這樣的時刻“當初要是這么做了該多好..”。
在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現(xiàn)出來，你的設計也可以達到相當高的邏輯水準，你通?？梢詮恼w上更好地了解數(shù)據(jù)庫設計所需要的方方面面。
了解你的業(yè)務
在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個數(shù)據(jù)表（怎么，你還沒有模式？那請你參看技巧 9）。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。
一旦你認為你已經(jīng)明確了業(yè)務內(nèi)容，你好同客戶進行系統(tǒng)的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數(shù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。