網(wǎng)站數(shù)據(jù)庫設計

網(wǎng)站數(shù)據(jù)庫設計一個成功的管理系統(tǒng)，是由：[50%的業(yè)務+50%的軟件]所組成，而50%的成功軟件又有[25%的數(shù)據(jù)庫+25%的程序]所組成，數(shù)據(jù)庫設計的好壞是一個關鍵。如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設計就是應用中最重要的一部分。有關數(shù)據(jù)庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。不過，就如我們反復強調的那樣，再好的老師也比不過經(jīng)驗的教誨。

插入一些數(shù)據(jù)庫設計心得：

設計思想

對許多程序員來說，設計一個數(shù)據(jù)庫應用程序并不是很難的一件事。但是卻有許多數(shù)據(jù)庫應用軟件得不到用戶的承認，其原因就是前期調研中，信息化設計單位和使用單位沒有得到相應的思想溝通。

這里所說的溝通包括用戶對軟件功能的要求，時間效益的要求，軟件平臺的要求，價格的要求和軟件維護的要求。這五種要求構成一個成功應用的軟件的所有的調研項目。

但是這里最重要的就是對軟件功能的要求，不同的企業(yè)對軟件要求的是不一樣的。下面就軟件功能的需求要求做一個概要介紹：

1．對象性：

這并不是軟件工程或者其他參考書中所描繪的軟件設計要求，但是這是一個必然的發(fā)展趨勢。我國軟件主要由財務軟件起步，財務業(yè)務流程是國家統(tǒng)一規(guī)定的，零售業(yè)的財務流程和建材業(yè)的財務業(yè)務流程并沒有多大不同，所以設計一種軟件就可以應用不同的公司甚至是跨行業(yè)的公司也就是很正常的一件事，但是隨著我國市場經(jīng)濟的發(fā)展，用信息化技術來推動企業(yè)發(fā)展成為一種切實有效的手段，許多不同行業(yè)的企業(yè)甚至同行業(yè)不同企業(yè)對信息化應用軟件都有不同的要求。

在現(xiàn)代程序開發(fā)技術中，面對對象的技術是一個大的飛躍。但是許多開發(fā)的數(shù)據(jù)庫應用軟件并沒由認識到這一點，所以開發(fā)的軟件就沒有市場。有一次，一個軟件推銷員到我公司來推銷軟件，是明煌軟件公司的人事管理軟件，公司人事部門領導很感興趣，隨口問了幾個問題，其中一個是有沒有臨時工的管理，一個是工資統(tǒng)計查詢能不能按照職工年齡，崗位，職稱，學歷分類統(tǒng)計查詢。結果這個軟件沒有這兩項功能，所以人事部門領導很客氣的拒絕了這個應用軟件推銷員的關于演示軟件的請求。

作為一個開發(fā)人員來說，在一個數(shù)據(jù)庫應用軟件加上以上兩個功能實在是很一般的工作，但是就是因為在開發(fā)時沒有面對對象的考慮用戶的需求導致了這次軟件推銷的失敗。

所以對一個應用軟件來說一開始就考慮軟件的對象性是一個成功的必要因素。

2．易用性

關于易用性的好壞不是由開發(fā)部門測定的，也不是由軟件評測機構認定的，而是由用戶認定的。這是在工作交流中得到確認的。

許多軟件考慮精細，例如ORACLE數(shù)據(jù)庫為后臺數(shù)據(jù)庫的ORACLE公司的ERP軟件解決方案，就沒有考慮到中國的國情，不但應用界面分類復雜，而且在工作業(yè)務繁忙的時候，由于操作復雜往往還適得其反，到耽誤了工作，惹得領導埋怨，職工抱怨，反而不如不用。

在銷售系統(tǒng)軟件的調試過程中，我認識了一個銷售公司的業(yè)務員，他跟我談了使用軟件后的許多感想。他說軟件本來是減輕工作量的，但是銷售系統(tǒng)有的應用界面就很不友好，在向網(wǎng)絡數(shù)據(jù)庫中錄入數(shù)據(jù)時，錄入數(shù)據(jù)很多，但是軟件總要求一會用鍵盤打字，一會用鼠標點擊，這幾千項數(shù)據(jù)輸入時，人一會用鍵盤一會用鼠標，活就像個鐘擺，累死了，干嗎不設計的都能用鍵盤控制呢。

事實上就是這樣，軟件在編制的過程中一定要多與業(yè)務人員交流，了解工作流程很重要，但是決不能忽視易用性在整個軟件性能中不可忽視的比例。

3．擴展性

作為現(xiàn)代軟件系統(tǒng)的一部分，可擴展性越來越成為構成軟件生命的主要功能之一。無論什么公司都希望買的軟件能夠適應并滿足公司業(yè)務發(fā)展變化的需求，還希望能夠和其他購買的軟件一起構成一個完整的企業(yè)軟件系統(tǒng)。

在軟件上來說，這有點困難，因為要滿足這項要求不但要預測企業(yè)發(fā)展方向，并且在軟件中預留出數(shù)據(jù)交換接口，在應用文檔中要公布部分數(shù)據(jù)庫構成甚至時部分源碼。

但是從大的應用方向上，我們設計的軟件必須達到這樣使用的功能。金蝶，用友這兩個大的軟件公司已經(jīng)實現(xiàn)的客戶開發(fā)工具包來實現(xiàn)客戶化二次開發(fā)的需求。

4．維護功能

為了保證軟件正常工作，軟件維護是必要的。但是遠水救不了近火，誰也不能保證軟件在故障的時候軟件維護人員能夠及時維護，這就要求在軟件設計是要增加軟件維護功能。有了軟件維護功能，哪怕是簡單的備份功能，也能夠在突發(fā)事件中將數(shù)據(jù)損失降到最低點。

除了一般功能外，在軟件設計時，我認為上述四個功能是注意要添加和完善的，這樣我們作出來的數(shù)據(jù)庫應用軟件才能夠具有更高的使用價值。

所以我歸納歷年來所走的彎路及體會，并在網(wǎng)上找了些對數(shù)據(jù)庫設計頗有造詣的專業(yè)人士給大家傳授一些設計數(shù)據(jù)庫的技巧和經(jīng)驗。精選了其中的60個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為5個部分：

第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ū)別。

如果采用了MicrosoftAccess，你可以用qry、rpt、tbl和mod等符號來標識對象（比如tbl_Employees）。我在和SQLServer打交道的時候還用過tbl來索引表，但我用sp_company（現(xiàn)在用sp_feft_）標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。我在實現(xiàn)SQLServer2000時用udf_（或者類似的標記）標識我編寫的函數(shù)。

工欲善其事,必先利其器

采用理想的數(shù)據(jù)庫設計工具，比如：SyBase公司的PowerDesign，她支持PB、VB、Delphe等語言，通過ODBC可以連接市面上流行的30多個數(shù)據(jù)庫，包括dBase、FoxPro、VFP、SQLServer等，今后有機會我將著重介紹PowerDesign的使用。

獲取數(shù)據(jù)模式資源手冊

正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由LenSilverston、W.H.Inmon和KentGraziano編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構和工作效能等。其他的你還可以參考：[1]薩師煊王珊著數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社1991、[2][美]StevenM.Bobrowski著Oracle7與客戶／服務器計算技術從入門到精通劉建元等譯電子工業(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è)務內容，你最好同客戶進行一次系統(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)大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今后能產(chǎn)生效益。

從輸入輸出下手

在定義數(shù)據(jù)庫表和字段需求（輸入）時，首先應檢查現(xiàn)有的或者已經(jīng)設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。

報表技巧

要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創(chuàng)建總結表。系統(tǒng)生成的主鍵在報表中很難管理。用戶在具有系統(tǒng)生成主鍵的表內用副鍵進行檢索往往會返回許多重復數(shù)據(jù)。這樣的檢索性能比較低而且容易引起混亂。

理解客戶需求

看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經(jīng)常詢問客戶保證其需求仍然在開發(fā)的目的之中。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。第2部分-設計表和字段檢查各種變化

我在設計數(shù)據(jù)庫的時候會考慮到哪些數(shù)據(jù)字段將來可能會發(fā)生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結婚后從夫姓等）。所以，在建立系統(tǒng)存儲客戶信息時，我傾向于在單獨的一個數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。

采用有意義的字段名

有一回我參加開發(fā)過一個項目，其中有從其他程序員那里繼承的程序，那個程序員喜歡用屏幕上顯示數(shù)據(jù)指示用語命名字段，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名采用了匈牙利命名和控制序號的組合形式，比如cbo1、txt2、txt2_b等等。

除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。當然，也別做過頭了，比如Customer_Shipping_Address_Street_Line_1，雖然很富有說明性，但沒人愿意鍵入這么長的名字，具體尺度就在你的把握中。

采用前綴命名

如果多個表里有好多同一類型的字段（比如FirstName），你不妨用特定表的前綴（比如CusLastName）來幫助你標識字段。

時效性數(shù)據(jù)應包括“最近更新日期/時間”字段。時間標記對查找數(shù)據(jù)問題的原因、按日期重新處理/重載數(shù)據(jù)和清除舊數(shù)據(jù)特別有用。

標準化和數(shù)據(jù)驅動

數(shù)據(jù)的標準化不僅方便了自己而且也方便了其他人。比方說，假如你的用戶界面要訪問外部數(shù)據(jù)源（文件、XML文檔、其他數(shù)據(jù)庫等），你不妨把相應的連接和路徑信息存儲在用戶界面支持表里。還有，如果用戶界面執(zhí)行工作流之類的任務（發(fā)送郵件、打印信箋、修改記錄狀態(tài)等），那么產(chǎn)生工作流的數(shù)據(jù)也可以存放在數(shù)據(jù)庫里。預先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅動而非硬編碼的方式，那么策略變更和維護都會方便得多。事實上，如果過程是數(shù)據(jù)驅動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。

標準化不能過頭

對那些不熟悉標準化一詞（normalization）的人而言，標準化可以保證表內的字段都是最基礎的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。標準化有好幾種形式，但ThirdNormalForm（3NF）通常被認為在性能、擴展性和數(shù)據(jù)完整性方面達到了最好平衡。簡單來說，3NF規(guī)定：

*表內的每一個值都只能被表達一次。

*表內的每一行都應該被唯一的標識（有唯一鍵）。

*表內不應該存儲依賴于其他鍵的非鍵信息。

遵守3NF標準的數(shù)據(jù)庫具有以下特點：有一組表專門存放通過鍵連接起來的關聯(lián)數(shù)據(jù)。比方說，某個存放客戶及其有關定單的3NF數(shù)據(jù)庫就可能有兩個表：Customer和Order。Order表不包含定單關聯(lián)客戶的任何信息，但表內會存放一個鍵值，該鍵指向Customer表里包含該客戶信息的那一行。

更高層次的標準化也有，但更標準是否就一定更好呢？答案是不一定。事實上，對某些項目來說，甚至就連3NF都可能給數(shù)據(jù)庫引入太高的復雜性。

為了效率的緣故，對表不進行標準化有時也是必要的，這樣的例子很多。曾經(jīng)有個開發(fā)餐飲分析軟件的活就是用非標準化表把查詢時間從平均40秒降低到了兩秒左右。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標準化當作當然的設計理念。而具體的操作不過是一種派生。所以如果表出了問題重新產(chǎn)生非標準化的表是完全可能的。

MicrosoftVisualFoxPro報表技巧

如果你正在使用MicrosoftVisualFoxPro，你可以用對用戶友好的字段名來代替編號的名稱：比如用CustomerName代替txtCNaM。這樣，當你用向導程序[Wizards，臺灣人稱為‘精靈’]創(chuàng)建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。

不活躍或者不采用的指示符

增加一個字段表示所在記錄是否在業(yè)務中不再活躍挺有用的。不管是客戶、員工還是其他什么人，這樣做都能有助于再運行查詢的時候過濾活躍或者不活躍狀態(tài)。同時還消除了新用戶在采用數(shù)據(jù)時所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時候可以起到一定的防范作用。

使用角色實體定義屬于某類別的列[字段]

在需要對屬于特定類別或者具有特定角色的事物做定義時，可以用角色實體來創(chuàng)建特定的時間關聯(lián)關系，從而可以實現(xiàn)自我文檔化。

這里的含義不是讓PERSON實體帶有Title字段，而是說，為什么不用PERSON實體和PERSON_TYPE實體來描述人員呢？比方說，當JohnSmith,Engineer提升為JohnSmith,Director乃至最后爬到JohnSmith,CIO的高位，而所有你要做的不過是改變兩個表PERSON和PERSON_TYPE之間關系的鍵值，同時增加一個日期/時間字段來知道變化是何時發(fā)生的。這樣，你的PERSON_TYPE表就包含了所有PERSON的可能類型，比如Associate、Engineer、Director、CIO或者CEO等。

還有個替代辦法就是改變PERSON記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。

采用常用實體命名機構數(shù)據(jù)

組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS和PHONE等等。當你把這些常用的一般名字組合起來或者創(chuàng)建特定的相應副實體時，你就得到了自己用的特殊版本。開始的時候采用一般術語的主要原因在于所有的具體用戶都能對抽象事物具體化。

有了這些抽象表示，你就可以在第2級標識中采用自己的特殊名稱，比如，PERSON可能是Employee、Spouse、Patient、Client、Customer、Vendor或者Teacher等。同樣的，ORGANIZATION也可能是MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government等。最后ADDRESS可以具體為Site、Location、Home、Work、Client、Vendor、Corporate和FieldOffice等。

采用一般抽象術語來標識“事物”的類別可以讓你在關聯(lián)數(shù)據(jù)以滿足業(yè)務要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。

用戶來自世界各地

在設計用到網(wǎng)絡或者具有其他國際特性的數(shù)據(jù)庫時，一定要記住大多數(shù)國家都有不同的字段格式，比如郵政編碼等，有些國家，比如新西蘭就沒有郵政編碼一說。

數(shù)據(jù)重復需要采用分立的數(shù)據(jù)表

如果你發(fā)現(xiàn)自己在重復輸入數(shù)據(jù)，請創(chuàng)建新表和新的關系。

每個表中都應該添加的3個有用的字段

*dRecordCreationDate，在VB下默認是Now()，而在SQLServer下默認為GETDATE()

*sRecordCreator，在SQLServer下默認為NOTNULLDEFAULTUSER

*nRecordVersion，記錄的版本標記；有助于準確說明記錄中出現(xiàn)null數(shù)據(jù)或者丟失數(shù)據(jù)的原因

對地址和電話采用多個字段

描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2和Address_Line3可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數(shù)據(jù)表，其間具有自身的類型和標記類別。

過分標準化可要小心，這樣做可能會導致性能上出現(xiàn)問題。雖然地址和電話表分離通常可以達到最佳狀態(tài)，但是如果需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如Customer等）更為妥當些。非標準化和加速訪問之間的妥協(xié)是有一定意義的。

使用多個名稱字段

我覺得很吃驚，許多人在數(shù)據(jù)庫里就給name留一個字段。我覺得只有剛入門的開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。我建議應該把姓氏和名字當作兩個字段來處理，然后在查詢的時候再把他們組合起來。

我最常用的是在同一表中創(chuàng)建一個計算列[字段]，通過它可以自動地連接標準化后的字段，這樣數(shù)據(jù)變動的時候它也跟著變。不過，這樣做在采用建模軟件時得很機靈才行。總之，采用連接字段的方式可以有效的隔離用戶應用和開發(fā)人員界面。

提防大小寫混用的對象名和特殊字符

過去最令我惱火的事情之一就是數(shù)據(jù)庫里有大小寫混用的對象名，比如CustomerData。這一問題從Access到Oracle數(shù)據(jù)庫都存在。我不喜歡采用這種大小寫混用的對象命名方法，結果還不得不手工修改名字。想想看，這種數(shù)據(jù)庫/應用程序能混到采用更強大數(shù)據(jù)庫的那一天嗎？采用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字符之間留空格。

小心保留詞

要保證你的字段名沒有和保留詞、數(shù)據(jù)庫系統(tǒng)或者常用訪問方法沖突，比如，最近我編寫的一個ODBC連接程序里有個表，其中就用了DESC作為說明字段名。后果可想而知！DESC是DESCENDING縮寫后的保留詞。表里的一個SELECT*語句倒是能用，但我得到的卻是一大堆毫無用處的信息。

保持字段名和類型的一致性

在命名字段并為其指定數(shù)據(jù)類型的時候一定要保證一致性。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。假如數(shù)據(jù)類型在一個表里是整數(shù)，那在另一個表里可就別變成字符型了。記住，你干完自己的活了，其他人還要用你的數(shù)據(jù)庫呢。

仔細選擇數(shù)字類型

在SQL中使用smallint和tinyint類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是smallint，那么，如果總額超過了$32,767你就不能進行計算操作了。

刪除標記

在表中包含一個“刪除標記”字段，這樣就可以把行標記為刪除。在關系數(shù)據(jù)庫里不要單獨刪除某一行；最好采用清除數(shù)據(jù)程序而且要仔細維護索引整體性。

避免使用觸發(fā)器

觸發(fā)器的功能通?？梢杂闷渌绞綄崿F(xiàn)。在調試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，你最好集中對它文檔化。

包含版本機制

建議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本。無論如何你都要實現(xiàn)這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數(shù)據(jù)庫結構。雖然你可以通過檢查新字段或者索引來確定數(shù)據(jù)庫結構的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎？。

給文本字段留足余量

ID類型的文本字段，比如客戶ID或定單號等等都應該設置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設你的客戶ID為10位數(shù)長。那你應該把數(shù)據(jù)庫表字段的長度設為12或者13個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長3個字符在有1百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù)3MB的空間。但這額外占據(jù)的空間卻無需將來重構整個數(shù)據(jù)庫就可以實現(xiàn)數(shù)據(jù)庫規(guī)模的增長了。身份證的號碼從15位變成18位就是最好和最慘痛的例子。

列[字段]命名技巧

我們發(fā)現(xiàn)，假如你給每個表的列[字段]名都采用統(tǒng)一的前綴，那么在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，后者把公共列[字段]名同某些數(shù)據(jù)庫聯(lián)系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設有兩個表：

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等。

這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的SQL語句可以寫成如下所示：

Select*FromCustomer,OrderWherecu_surname="MYNAME";

andcu_name_id=or_cust_name_idandor_quantity=1

在沒有這些前綴的情況下則寫成這個樣子（用別名來區(qū)分）：

Select*FromCustomer,OrderWhereCustomer.surname="MYNAME";

andC_id=Order.cust_name_idandOrder.quantity=1

第1個SQL語句沒少鍵入多少字符。但如果查詢涉及到5個表乃至更多的列[字段]你就知道這個技巧多有用第3部分-選擇鍵和索引數(shù)據(jù)采掘要預先計劃

我所在的某一客戶部門一度要處理8萬多份聯(lián)系方式，同時填寫每個客戶的必要數(shù)據(jù)（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數(shù)據(jù)庫的運行速度。然后我意識到特定的組查詢和信息采掘既不準確速度也不快。結果只好在主索引中重建而且合并了數(shù)據(jù)字段。我發(fā)現(xiàn)有一個指示計劃相當關鍵——當我想創(chuàng)建系統(tǒng)類型查找時為什么要采用號碼作為主索引字段呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統(tǒng)類型一樣對我來說并不重要。采用后者作為主字段，數(shù)據(jù)庫更新后重新索引和檢索就快多了。

可操作數(shù)據(jù)倉庫（ODS）和數(shù)據(jù)倉庫（DW）這兩種環(huán)境下的數(shù)據(jù)索引是有差別的。在DW環(huán)境下，你要考慮銷售部門是如何組織銷售活動的。他們并不是數(shù)據(jù)庫管理員，但是他們確定表內的鍵信息。這里設計人員或者數(shù)據(jù)庫工作人員應該分析數(shù)據(jù)庫結構從而確定出性能和正確輸出之間的最佳條件。

使用系統(tǒng)生成的主鍵

這類同技巧1，但我覺得有必要在這里重復提醒大家。假如你總是在設計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。這樣，數(shù)據(jù)庫和非人工機制就有效地控制了對存儲數(shù)據(jù)中每一行的訪問。

采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。

分解字段用于索引

為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進行索引。索引將加快SQL和報表生成器腳本的執(zhí)行速度。比方說，我通常在必須使用SQLLIKE表達式的情況下創(chuàng)建報表，因為casenumber字段無法分解為year、serialnumber、casetype和defendantcode等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。

鍵設計4原則

*為關聯(lián)字段創(chuàng)建外鍵。

*所有的鍵都必須唯一。

*避免使用復合鍵。

*外鍵總是關聯(lián)唯一的鍵字段。

別忘了索引

索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)的最高效方式之一。95%的數(shù)據(jù)庫性能問題都可以采用索引技術得到解決。作為一條規(guī)則，我通常對邏輯主鍵使用唯一的成組索引，對系統(tǒng)鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列[字段]采用非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮數(shù)據(jù)庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。

大多數(shù)數(shù)據(jù)庫都索引自動創(chuàng)建的主鍵字段，但是可別忘了索引外鍵，它們也是經(jīng)常使用的鍵，比如運行查詢顯示主表和所有關聯(lián)表的某條記錄就用得上。還有，不要索引memo/note字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。

不要索引常用的小型表

不要為小型數(shù)據(jù)表設置任何鍵，假如它們經(jīng)常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

不要把社會保障號碼（SSN）或身份證號碼（ID）選作鍵

永遠都不要使用SSN或ID作為數(shù)據(jù)庫的鍵。除了隱私原因以外，須知政府越來越趨向于不準許把SSN或ID用作除收入相關以外的其他目的，SSN或ID需要手工輸入。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然后從頭開始。

我在破解他人的程序時候，我看到很多人把SSN或ID還曾被用做系列號，當然盡管這么做是非法的。而且人們也都知道這是非法的，但他們已經(jīng)習慣了。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把SSN或ID刪除。

不要用用戶的鍵

在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。這樣做會迫使你采取以下兩個措施：

*在創(chuàng)建記錄之后對用戶編輯字段的行為施加限制。假如你這么做了，你可能會發(fā)現(xiàn)你的應用程序在商務需求突然發(fā)生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當用戶在輸入數(shù)據(jù)之后直到保存記錄才發(fā)現(xiàn)系統(tǒng)出了問題他們該怎么想？刪除重建？假如記錄不可重建是否讓用戶走開？

*提出一些檢測和糾正鍵沖突的方法。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的數(shù)據(jù)和商業(yè)/用戶界面層之間的隔離。

所以還是重提一句老話：你的設計要適應用戶而不是讓用戶來適應你的設計。

不讓主鍵具有可更新性的原因是在關系模式下，主鍵實現(xiàn)了不同表之間的關聯(lián)。比如，Customer表有一個主鍵CustomerID，而客戶的定單則存放在另一個表里。Order表的主鍵可能是OrderNo或者OrderNo、CustomerID和日期的組合。不管你選擇哪種鍵設置，你都需要在Order表中存放CustomerID來保證你可以給下定單的用戶找到其定單記錄。

假如你在Customer表里修改了CustomerID，那么你必須找出Order表中的所有相關記錄對其進行修改。否則，有些定單就會不屬于任何客戶——數(shù)據(jù)庫的完整性就算完蛋了。

如果索引完整性規(guī)則施加到表一級，那么在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數(shù)據(jù)庫內所有關聯(lián)的記錄。而這一過程往往錯誤叢生所以應該盡量避免。

可選鍵(候選鍵)有時可做主鍵

記住，查詢數(shù)據(jù)的不是機器而是人。

假如你有可選鍵，你可能進一步把它用做主鍵。那樣的話，你就擁有了建立強大索引的能力。這樣可以阻止使用數(shù)據(jù)庫的人不得不連接數(shù)據(jù)庫從而恰當?shù)倪^濾數(shù)據(jù)。在嚴格控制域表的數(shù)據(jù)庫上，這種負載是比較醒目的。如果可選鍵真正有用，那就是達到了主鍵的水準。

我的看法是，假如你有可選鍵，比如國家表內的state_code，你不要在現(xiàn)有不能變動的唯一鍵上創(chuàng)建后續(xù)的鍵。你要做的無非是創(chuàng)建毫無價值的數(shù)據(jù)。如你因為過度使用表的后續(xù)鍵[別名]建立這種表的關聯(lián)，操作負載真得需要考慮一下了。

別忘了外鍵

大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建的主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中的記錄及其關聯(lián)記錄時每次都會用到。還有，不要索引memo/notes字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引占據(jù)大量的數(shù)據(jù)庫空間。第4部分-保證數(shù)據(jù)的完整性用約束而非商務規(guī)則強制數(shù)據(jù)完整性

如果你按照商務規(guī)則來處理需求，那么你應當檢查商務層次/用戶界面：如果商務規(guī)則以后發(fā)生變化，那么只需要進行更新即可。假如需求源于維護數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。如果你在數(shù)據(jù)層確實采用了約束，你要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，否則字段名本身還不夠。

只要有可能，請采用數(shù)據(jù)庫系統(tǒng)實現(xiàn)數(shù)據(jù)的完整性。這不但包括通過標準化實現(xiàn)的完整性而且還包括數(shù)據(jù)的功能性。在寫數(shù)據(jù)的時候還可以增加觸發(fā)器來保證數(shù)據(jù)的正確性。不要依賴于商務層保證數(shù)據(jù)完整性；它不能保證表之間（外鍵）的完整性所以不能強加于其他完整性規(guī)則之上。

分布式數(shù)據(jù)系統(tǒng)

對分布式系統(tǒng)而言，在你決定是否在各個站點復制所有數(shù)據(jù)還是把數(shù)據(jù)保存在一個地方之前應該估計一下未來5年或者10年的數(shù)據(jù)量。當你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設置一些標記。在目的站點收到你的數(shù)據(jù)之后更新你的標記。為了進行這種數(shù)據(jù)傳輸，請寫下你自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數(shù)據(jù)。本地拷貝你的維護數(shù)據(jù)，比如計算常數(shù)和利息率等，設置版本號保證數(shù)據(jù)在每個站點都完全一致。

強制指示完整性(參照完整性?)

沒有好辦法能在有害數(shù)據(jù)進入數(shù)據(jù)庫之后消除它，所以你應該在它進入數(shù)據(jù)庫之前將其剔除。激活數(shù)據(jù)庫系統(tǒng)的指示完整性特性。這樣可以保持數(shù)據(jù)的清潔而能迫使開發(fā)人員投入更多的時間處理錯誤條件。

關系

如果兩個實體之間存在多對一關系，而且還有可能轉化為多對多關系，那么你最好一開始就設置成多對多關系。從現(xiàn)有的多對一關系轉變?yōu)槎鄬Χ嚓P系