數(shù)據(jù)庫設(shè)計方案設(shè)計數(shù)據(jù)庫之前考查現(xiàn)有環(huán)境

在設(shè)計一個新數(shù)據(jù)庫時，你不但應(yīng)該仔細(xì)研究業(yè)務(wù)需求而且還要考查現(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ā)覺一些可能會忽略細(xì)微問題。通常來說，考查現(xiàn)有系統(tǒng)對你絕對有好處。

定義標(biāo)準(zhǔn)對象命名規(guī)范

一定要定義數(shù)據(jù)庫對象命名規(guī)范。對數(shù)據(jù)庫表來說，從項目一開始就要確定表名是采取復(fù)數(shù)還是單數(shù)形式。另外還要給表別名定義簡單規(guī)則（比喻說，假如表名是一個單詞，別名就取單詞前4個字母；假如表名是兩個單詞，就各取兩個單詞前兩個字母組成4個字母長別名；假如表名字由3個單詞組成，你不妨從頭兩個單詞中各取一個然后從最終一個單詞中再取出兩個字母，結(jié)果還是組成4字母長別名，其余依次類推）對工作用表來說，表名能夠加上前綴WORK_后面附上采取該表應(yīng)用程序名字。表內(nèi)列[字段]要針對鍵采取一整套設(shè)計規(guī)則。比如，假如鍵是數(shù)字類型，你能夠用_N作為后綴；假如是字符類型則能夠采取_C后綴。對列[字段]名應(yīng)該采取標(biāo)準(zhǔn)前綴和后綴。再如，假如你表里有好多“money”字段，你不妨給每個列[字段]增加一個_M后綴。還有，日期列[字段]最好以D_作為名字打頭。

檢驗表名、報表名和查詢名之間命名規(guī)范。你可能會很快就被這些不一樣數(shù)據(jù)庫要素名稱搞糊涂了。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫不一樣組成部分，最少你應(yīng)該在這些對象名字開頭用Table、Query或者Report等前綴加以區(qū)分。假如采取了MicrosoftAccess，你能夠用qry、rpt、tbl和mod等符號來標(biāo)識對象（比如tbl_Employees）。我在和SQLServer打交道時候還用過tbl來索引表，但我用sp_company（現(xiàn)在用sp_feft_）標(biāo)識存放過程，因為在有時候假如我發(fā)覺了愈加好處理方法往往會保留好幾個拷貝。我在實現(xiàn)SQLServer時用udf_（或者類似標(biāo)識）標(biāo)識我編寫函數(shù)。

工欲善其事,

必先利其器

采取理想數(shù)據(jù)庫設(shè)計工具，比如：SyBase企業(yè)PowerDesign，她支持PB、VB、Delphe等語言，經(jīng)過ODBC能夠連接市面上流行30多個數(shù)據(jù)庫，包含dBase、FoxPro、VFP、SQLServer等，今后有機會我將著重介紹PowerDesign使用。

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

正在尋求示例模式人能夠閱讀《數(shù)據(jù)模式資源手冊》一書，該書由LenSilverston、W.H.Inmon和KentGraziano編寫，是一本值得擁有最好數(shù)據(jù)建模圖書。該書包含章節(jié)涵蓋多個數(shù)據(jù)領(lǐng)域，比如人員、機構(gòu)和工作效能等。其余你還能夠參考：[1]薩師煊王珊著數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社1991、[2][美]StevenM.Bobrowski著Oracle7與客戶／服務(wù)器計算技術(shù)從入門到精通劉建元等譯電子工業(yè)出版社，1996、[3]周中元信息系統(tǒng)建模方法(下)電子與信息化1999年第3期，1999

暢想未來，但不可忘了過去教訓(xùn)

我發(fā)覺問詢用戶怎樣對待未來需求改變非常有用。這么做能夠達成兩個目標(biāo)：首先，你能夠清楚地了解應(yīng)用設(shè)計在哪個地方應(yīng)該更具靈活性以及怎樣防止性能瓶頸；其次，你知道發(fā)生事先沒有確定需求變更時用戶將和你一樣感到吃驚。一定要記住過去經(jīng)驗教訓(xùn)！我們開發(fā)人員還應(yīng)該經(jīng)過分享自己體會和經(jīng)驗相互幫助。即使用戶認(rèn)為他們再也不需要什么支持了，我們也應(yīng)該對他們進行這方面教育，我們都曾經(jīng)面臨過這么時刻“當(dāng)初要是這么做了該多好..”。

在物理實踐之前進行邏輯設(shè)計

在深入物理設(shè)計之前要先進行邏輯設(shè)計。伴隨大量CASE工具不停涌現(xiàn)出來，你設(shè)計也能夠達成相當(dāng)高邏輯水準(zhǔn)，你通常能夠從整體上愈加好地了解數(shù)據(jù)庫設(shè)計所需要方方面面。

了解你業(yè)務(wù)

在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你ER（實體關(guān)系）模式中加入哪怕一個數(shù)據(jù)表（怎么，你還沒有模式？那請你參看技巧9）。了解你企業(yè)業(yè)務(wù)能夠在以后開發(fā)階段節(jié)約大量時間。一旦你明確了業(yè)務(wù)需求，你就能夠自己做出許多決議了。

一旦你認(rèn)為你已經(jīng)明確了業(yè)務(wù)內(nèi)容，你最好同客戶進行一次系統(tǒng)交流。采取客戶術(shù)語而且向他們解釋你所想到和你所聽到。同時還應(yīng)該用可能、將會和必須等詞匯表示出系統(tǒng)關(guān)系基數(shù)。這么你就能夠讓你客戶糾正你自己了解然后做好下一步ER設(shè)計。

創(chuàng)建數(shù)據(jù)字典和

ER

圖表

一定要花點時間創(chuàng)建ER圖表和數(shù)據(jù)字典。其中最少應(yīng)該包含每個字段數(shù)據(jù)類型和在每個表內(nèi)主外鍵。創(chuàng)建ER圖表和數(shù)據(jù)字典確實有點費時但對其余開發(fā)人員要了解整個設(shè)計卻是完全必要。越早創(chuàng)建越能有利于防止今后面臨可能混亂，從而能夠讓任何了解數(shù)據(jù)庫人都明確怎樣從數(shù)據(jù)庫中取得數(shù)據(jù)。有一份諸如ER圖表等最新文檔其主要性怎樣強調(diào)都不過分，這對表明表之間關(guān)系很有用，而數(shù)據(jù)字典則說明了每個字段用途以及任何可能存在別名。對SQL表示式文檔化來說這是完全必要。

創(chuàng)建模式

一張圖表勝過千言萬語：開發(fā)人員不但要閱讀和實現(xiàn)它，而且還要用它來幫助自己和用戶對話。模式有利于提升協(xié)作效能，這么在先期數(shù)據(jù)庫設(shè)計中幾乎不可能出現(xiàn)大問題。模式無須弄很復(fù)雜；甚至能夠簡單到手寫在一張紙上就能夠了。只是要確保其上邏輯關(guān)系今后能產(chǎn)生效益。

從輸入輸出下手

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

報表技巧

要了解用戶通常是怎樣匯報數(shù)據(jù)：批處理還是在線提交報表？時間間隔是天天、每七天、每個月、每個季度還是每年？假如需要話還能夠考慮創(chuàng)建總結(jié)表。系統(tǒng)生成主鍵在報表中極難管理。用戶在具備系統(tǒng)生成主鍵表內(nèi)用副鍵進行檢索往往會返回許多重復(fù)數(shù)據(jù)。這么檢索性能比較低而且輕易引發(fā)混亂。

了解客戶需求

看起來這應(yīng)該是顯而易見事，但需求就是來自客戶（這里要從內(nèi)部和外部客戶角度考慮）。不要依賴用戶寫下來需求，真正需求在客戶腦袋里。你要讓客戶解釋其需求，而且伴隨開發(fā)繼續(xù)，還要經(jīng)常問詢客戶確保其需求依然在開發(fā)目標(biāo)之中。一個不變真理是：“只有我看見了我才知道我想要是什么”必定會造成大量返工，因為數(shù)據(jù)庫沒有達成客戶從來沒有寫下來需求標(biāo)準(zhǔn)。而更糟是你對他們需求解釋只屬于你自己，而且可能是完全錯誤。

設(shè)計數(shù)據(jù)庫表檢驗各種改變

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

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

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

3、采取前綴命名

假如多個表里有好多同一類型字段（比如FirstName），你不妨用特定表前綴（比如CusLastName）來幫助你標(biāo)識字段。時效性數(shù)據(jù)應(yīng)包含“最近更新日期/時間”字段。時間標(biāo)識對查找數(shù)據(jù)問題原因、按日期重新處理/重載數(shù)據(jù)和去除舊數(shù)據(jù)尤其有用。

標(biāo)準(zhǔn)化和數(shù)據(jù)驅(qū)動

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

標(biāo)準(zhǔn)化不能過頭

對那些不熟悉標(biāo)準(zhǔn)化一詞（normalization）人而言，標(biāo)準(zhǔn)化能夠確保表內(nèi)字段都是最基礎(chǔ)要素，而這一方法有利于消除數(shù)據(jù)庫中數(shù)據(jù)冗余。標(biāo)準(zhǔn)化有好幾個形式，但ThirdNormalForm（3NF）通常被認(rèn)為在性能、擴展性和數(shù)據(jù)完整性方面達成了最好平衡。簡單來說，3NF要求：

*表內(nèi)每一個值都只能被表示一次。

*表內(nèi)每一行都應(yīng)該被唯一標(biāo)識（有唯一鍵）。

*表內(nèi)不應(yīng)該存放依賴于其余鍵非鍵信息。

恪守3NF標(biāo)準(zhǔn)數(shù)據(jù)庫具備以下特點：有一組表專門存放經(jīng)過鍵連接起來關(guān)聯(lián)數(shù)據(jù)。比喻說，某個存放客戶及其關(guān)于定單3NF數(shù)據(jù)庫就可能有兩個表：Customer和Order。Order表不包含定單關(guān)聯(lián)客戶任何信息，但表內(nèi)會存放一個鍵值，該鍵指向Customer表里包含該客戶信息那一行。

更高層次標(biāo)準(zhǔn)化也有，但更標(biāo)準(zhǔn)是否就一定愈加好呢？答案是不一定。實際上，對一些項目來說，甚至就連3NF都可能給數(shù)據(jù)庫引入太高復(fù)雜性。為了效率緣故，對表不進行標(biāo)準(zhǔn)化有時也是必要，這么例子很多。曾經(jīng)有個開發(fā)餐飲分析軟件活就是用非標(biāo)準(zhǔn)化表把查詢時間從平均40秒降低到了兩秒左右。即使我不得不這么做，但我絕不把數(shù)據(jù)表非標(biāo)準(zhǔn)化看成當(dāng)然設(shè)計理念。而詳細(xì)操作不過是一個派生。所以假如表出了問題重新產(chǎn)生非標(biāo)準(zhǔn)化表是完全可能。

MicrosoftVisualFoxPro

報表技巧

假如你正在使用MicrosoftVisualFoxPro，你能夠用對用戶友好字段名來代替編號名稱：比如用CustomerName代替txtCNaM。這么，當(dāng)你用向?qū)С绦騕Wizards，臺灣人稱為‘精靈’]創(chuàng)建表單和報表時，其名字會讓那些不是程序員人更輕易閱讀。

不活躍或者不采取指示符

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

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

在需要對屬于特定類別或者具備特定角色事物做定義時，能夠用角色實體來創(chuàng)建特定時間關(guān)聯(lián)關(guān)系，從而能夠?qū)崿F(xiàn)自我文檔化。

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

還有個代替方法就是改變PERSON統(tǒng)計來反應(yīng)新頭銜改變，不過這么一來在時間上無法跟蹤個人所處位置詳細(xì)時間。

采取慣用實體命名機構(gòu)數(shù)據(jù)

組織數(shù)據(jù)最簡單方法就是采取慣用名字，比如：PERSON、ORGANIZATION、ADDRESS和PHONE等等。當(dāng)你把這些慣用通常名字組合起來或者創(chuàng)建特定對應(yīng)副實體時，你就得到了自己用特殊版本。開始時候采取通常術(shù)語主要原因在于全部詳細(xì)用戶都能對抽象事物詳細(xì)化。

有了這些抽象表示，你就能夠在第2級標(biāo)識中采取自己特殊名稱，比如，PERSON可能是Employee、Spouse、Patient、Client、Customer、Vendor或者Teacher等。一樣，ORGANIZATION也可能是MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government等。最終ADDRESS能夠詳細(xì)為Site、Location、Home、Work、Client、Vendor、Corporate和FieldOffice等。

采取通常抽象術(shù)語來標(biāo)識“事物”類別能夠讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面取得巨大靈活性，同時這么做還能夠顯著降低數(shù)據(jù)存放所需冗余量。

用戶來自世界各地

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

數(shù)據(jù)重復(fù)需要采取分立數(shù)據(jù)表

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

每個表中都應(yīng)該添加

3

個有用字段

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

*sRecordCreator，在SQLServer下默認(rèn)為NOTNULLDEFAULTUSER

*nRecordVersion，統(tǒng)計版本標(biāo)識；有利于準(zhǔn)確說明統(tǒng)計中出現(xiàn)null數(shù)據(jù)或者丟失數(shù)據(jù)原因

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

描述街道地址就短短一行統(tǒng)計是不夠。Address_Line1、Address_Line2和Address_Line3能夠提供更大靈活性。還有，電話號碼和郵件地址最好擁有自己數(shù)據(jù)表，其間具備本身類型和標(biāo)識類別。過分標(biāo)準(zhǔn)化可要小心，這么做可能會造成性能上出現(xiàn)問題。即使地址和電話表分離通常能夠達成最好狀態(tài)，不過假如需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如Customer等）更為妥當(dāng)些。非標(biāo)準(zhǔn)化和加速訪問之間妥協(xié)是有一定意義。

使用多個名稱字段

我以為很吃驚，許多人在數(shù)據(jù)庫里就給name留一個字段。我以為只有剛?cè)腴T開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。我提議應(yīng)該把姓氏和名字看成兩個字段來處理，然后在查詢時候再把他們組合起來。

我最慣用是在同一表中創(chuàng)建一個計算列[字段]，經(jīng)過它能夠自動地連接標(biāo)準(zhǔn)化后字段，這么數(shù)據(jù)變動時候它也跟著變。不過，這么做在采取建模軟件時得很靈巧才行。總之，采取連接字段方式能夠有效隔離用戶應(yīng)用和開發(fā)人員界面。

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

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

小心保留詞

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

保持字段名和類型一致性

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

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

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

刪除標(biāo)識

在表中包含一個“刪除標(biāo)識”字段，這么就能夠把行標(biāo)識為刪除。在關(guān)系數(shù)據(jù)庫里不要單獨刪除某一行；最好采取去除數(shù)據(jù)程序而且要仔細(xì)維護索引整體性。

防止使用觸發(fā)器

觸發(fā)器功效通常能夠用其余方式實現(xiàn)。在調(diào)試程序時觸發(fā)器可能成為干擾。假如你確實需要采取觸發(fā)器，你最好集中對它文檔化。

包含版本機制

提議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中數(shù)據(jù)庫版本。不論怎樣你都要實現(xiàn)這一要求。時間一長，用戶需求總是會改變。最終可能會要求修改數(shù)據(jù)庫結(jié)構(gòu)。即使你能夠經(jīng)過檢驗新字段或者索引來確定數(shù)據(jù)庫結(jié)構(gòu)版本，但我發(fā)覺把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎？。

給文本字段留足余量

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

列[字段]命名技巧

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

Customer和Order。Customer表前綴是cu_，所以該表內(nèi)子段名以下：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語句能夠?qū)懗梢韵滤硎荆?/p>

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個表乃至更多列[字段]你就知道這個技巧多有用了。

選擇鍵和索引數(shù)據(jù)采掘要預(yù)先計劃

我所在某一客戶部門一度要處理8萬多份聯(lián)絡(luò)方式，同時填寫每個客戶必要數(shù)據(jù)（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標(biāo)。當(dāng)我從最開始設(shè)計表和字段時候，我試圖不在主索引里增加太多字段方便加緊數(shù)據(jù)庫運行速度。然后我意識到特定組查詢和信息采掘既不準(zhǔn)確速度也不快。結(jié)果只好在主索引中重建而且合并了數(shù)據(jù)字段。我發(fā)覺有一個指示計劃相當(dāng)關(guān)鍵——當(dāng)我想創(chuàng)建系統(tǒng)類型查找時為何要采取號碼作為主索引字段呢？我能夠用傳真號碼進行檢索，不過它幾乎就象系統(tǒng)類型一樣對我來說并不主要。采取后者作為主字段，數(shù)據(jù)庫更新后重新索引和檢索就快多了?？刹僮鲾?shù)據(jù)倉庫（ODS）和數(shù)據(jù)倉庫（DW）這兩種環(huán)境下數(shù)據(jù)索引是有差異。在DW環(huán)境下，你要考慮銷售部門是怎樣組織銷售活動。他們并不是數(shù)據(jù)庫管理員，不過他們確定表內(nèi)鍵信息。這里設(shè)計人員或者數(shù)據(jù)庫工作人員應(yīng)該分析數(shù)據(jù)庫結(jié)構(gòu)從而確定出性能和正確輸出之間最好條件。

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

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

采取系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當(dāng)你擁有一致鍵結(jié)構(gòu)時，找到邏輯缺點很輕易。

分解字段用于索引

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

鍵設(shè)計

4

標(biāo)準(zhǔn)

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

*全部鍵都必須唯一。

*防止使用復(fù)合鍵。

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

別忘了索引

索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)最高效方式之一。95%數(shù)據(jù)庫性能問題都能夠采取索引技術(shù)得到處理。作為一條規(guī)則，我通常對邏輯主鍵使用唯一成組索引，對系統(tǒng)鍵（作為存放過程）采取唯一非成組索引，對任何外鍵列[字段]采取非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮數(shù)據(jù)庫空間有多大，表怎樣進行訪問，還有這些訪問是否主要用作讀寫。大多數(shù)數(shù)據(jù)庫都索引自動創(chuàng)建主鍵字段，不過可別忘了索引外鍵，它們也是經(jīng)常使用鍵，比如運行查詢顯示主表和所關(guān)于聯(lián)表某條統(tǒng)計就用得上。還有，不要索引memo/note字段，不要索引大型字段（有很多字符），這么作會讓索引占用太多存放空間。

不要索引慣用小型表

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

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

永遠(yuǎn)都不要使用SSN或ID作為數(shù)據(jù)庫鍵。除了隱私原因以外，須知政府越來越趨向于不準(zhǔn)許把SSN或ID用作除收入相關(guān)以外其余目標(biāo)，SSN或ID需要手工輸入。永遠(yuǎn)不要使用手工輸入鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做就是刪除整個統(tǒng)計然后從頭開始。我在破解他人程序時候，我看到很多人把SSN或ID還曾被用做系列號，當(dāng)然盡管這么做是非法。而且人們也都知道這是非法，但他們已經(jīng)習(xí)慣了。日后，伴隨盜取身份犯罪案件增加，我現(xiàn)在同行正痛苦地從一大攤子數(shù)據(jù)中把SSN或ID刪除。

不要用用戶鍵

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

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

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

所以還是重提一句老話：你設(shè)計要適應(yīng)用戶而不是讓用戶來適應(yīng)你設(shè)計。

不讓主鍵具備可更新性原因是在關(guān)系模式下，主鍵實現(xiàn)了不一樣表之間關(guān)聯(lián)。比如，Customer表有一個主鍵CustomerID，而客戶定單則存放在另一個表里。Order表主鍵可能是OrderNo或者OrderNo、CustomerID和日期組合。不論你選擇哪種鍵設(shè)置，你都需要在Order表中存放CustomerID來確保你能夠給下定單用戶找到其定單統(tǒng)計。

假如你在Customer表里修改了CustomerID，那么你必須找出Order表中全部相關(guān)統(tǒng)計對其進行修改。不然，有些定單就會不屬于任何客戶——數(shù)據(jù)庫完整性就算完蛋了。

假如索引完整性規(guī)則施加到表一級，那么在不編寫大量代碼和附加刪除統(tǒng)計情況下幾乎不可能改變某一條統(tǒng)計鍵和數(shù)據(jù)庫內(nèi)所關(guān)于聯(lián)統(tǒng)計。而這一過程往往錯誤叢生所以應(yīng)該盡可能防止。

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

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

假如你有可選鍵，你可能深入把它用做主鍵。那樣話，你就擁有了建立強大索引能力。這么能夠阻止使用數(shù)據(jù)庫人不得不連接數(shù)據(jù)庫從而恰當(dāng)過濾數(shù)據(jù)。在嚴(yán)格控制域表數(shù)據(jù)庫上，這種負(fù)載是比較醒目標(biāo)。假如可選鍵真正有用，那就是達成了主鍵水準(zhǔn)。

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

別忘了外鍵

大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中統(tǒng)計及其關(guān)聯(lián)統(tǒng)計時每次都會用到。還有，不要索引memo/notes字段而且不要索引大型文本字段（許多字符），這么做會讓你索引占據(jù)大量數(shù)據(jù)庫空間。

確保數(shù)據(jù)完整性用約束而非商務(wù)規(guī)則強制數(shù)據(jù)完整性

假如你按照商務(wù)規(guī)則來處理需求，那么你應(yīng)該檢驗商務(wù)層次/用戶界面：假如商務(wù)規(guī)則以后發(fā)生改變，那么只需要進行更新即可。假如需求源于維護數(shù)據(jù)完整性需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。假如你在數(shù)據(jù)層確實采取了約束，你要確保有方法把更新不能經(jīng)過約束檢驗原因采取用戶了解語言通知用戶界面。除非你字段命名很冗長，不然字段名本身還不夠。只要有可能，請采取數(shù)據(jù)庫系統(tǒng)實現(xiàn)數(shù)據(jù)完整性。這不但包含經(jīng)過標(biāo)準(zhǔn)化實現(xiàn)完整性而且還包含數(shù)據(jù)功效性。在寫數(shù)據(jù)時候還能夠增加觸發(fā)器來確保數(shù)據(jù)正確性。不要依賴于商務(wù)層確保數(shù)據(jù)完整性；它不能確保表之間（外鍵）完整性所以不能強加于其余完整性規(guī)則之上。

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

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

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

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

關(guān)系

假如兩個實體之間存在多對一關(guān)系，而且還有可能轉(zhuǎn)化為多對多關(guān)系，那么你最好一開始就設(shè)置成多對多關(guān)系。從現(xiàn)有多對一關(guān)系轉(zhuǎn)變?yōu)槎鄬Χ嚓P(guān)系比一開始就是多對多關(guān)系要難得多。

采取視圖

為了在你數(shù)據(jù)庫和你應(yīng)用程序代碼之間提供另一層抽象，你能夠為你應(yīng)用程序建立專門視圖而無須非要應(yīng)用程序直接訪問數(shù)據(jù)表。這么做還等于在處理數(shù)據(jù)庫變更時給你提供了更多自由。

給數(shù)據(jù)保有和恢復(fù)制訂計劃

考慮數(shù)據(jù)保有策略并包含在設(shè)計過程中，預(yù)先設(shè)計你數(shù)據(jù)恢復(fù)過程。采取能夠公布給用戶/開發(fā)人員數(shù)據(jù)字典實現(xiàn)方便數(shù)據(jù)識別同時確保對數(shù)據(jù)源文檔