【正文】 F 標(biāo)準(zhǔn)的數(shù)據(jù)庫具有以下特點：有一組表專門存放通過鍵連接起來的關(guān)聯(lián)數(shù)據(jù)。這里的含義不是讓 PERSON 實體帶有 Title 字段，而是說，為什么不用 PERSON 實體和 PERSON_TYPE 實體來描述人員呢？比方說，當(dāng) John Smith, Engineer 提升為 John Smith, Director 乃至最后爬到 John Smith, CIO 的高位，而所有你要做的不過是改變兩個表 PERSON 和 PERSON_TYPE 之間關(guān)系的鍵值，同時增加一個日期/時間字段來知道變化是何時發(fā)生的。雖然地址和電話表分離通?？梢赃_(dá)到最佳狀態(tài)，但是如果需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如 Customer 等）更為妥當(dāng)些。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。那你應(yīng)該把數(shù)據(jù)庫表字段的長度設(shè)為 12 或者 13 個字符長。然后我意識到特定的組查詢和信息采掘既不準(zhǔn)確速度也不快。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。永遠(yuǎn)不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然后從頭開始。假如你在 Customer 表里修改了 CustomerID，那么你必須找出 Order 表中的所有相關(guān)記錄對其進(jìn)行修改。 第 4 部分 保證數(shù)據(jù)的完整性用約束而非商務(wù)規(guī)則強制數(shù)據(jù)完整性如果你按照商務(wù)規(guī)則來處理需求，那么你應(yīng)當(dāng)檢查商務(wù)層次/用戶界面：如果商務(wù)規(guī)則以后發(fā)生變化，那么只需要進(jìn)行更新即可。 關(guān)系如果兩個實體之間存在多對一關(guān)系，而且還有可能轉(zhuǎn)化為多對多關(guān)系，那么你最好一開始就設(shè)置成多對多關(guān)系。取決于你使用的數(shù)據(jù)庫系統(tǒng)，可能有一些軟件會給你一些供你很快上手的文檔。 檢查設(shè)計在開發(fā)期間檢查數(shù)據(jù)庫設(shè)計的常用技術(shù)是通過其所支持的應(yīng)用程序原型檢查數(shù)據(jù)庫。這樣可以實現(xiàn)一種簡單機制跟蹤數(shù)據(jù)庫，當(dāng)客戶抱怨他們的數(shù)據(jù)庫沒有達(dá)到希望的要求而與你聯(lián)系時，這樣做對非客戶機/服務(wù)器環(huán)境特別有用。某些公共數(shù)據(jù)特別適合查找：國家代碼、狀態(tài)代碼等。本地拷貝你的維護(hù)數(shù)據(jù)，比如計算常數(shù)和利息率等，設(shè)置版本號保證數(shù)據(jù)在每個站點都完全一致。如你因為過度使用表的后續(xù)鍵[別名]建立這種表的關(guān)聯(lián)，操作負(fù)載真得需要考慮一下了。不讓主鍵具有可更新性的原因是在關(guān)系模式下，主鍵實現(xiàn)了不同表之間的關(guān)聯(lián)。 不要索引常用的小型表不要為小型數(shù)據(jù)表設(shè)置任何鍵，假如它們經(jīng)常有插入和刪除操作就更別這樣作了。 分解字段用于索引為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進(jìn)行索引。但如果查詢涉及到 5 個表乃至更多的列[字段]你就知道這個技巧多有用了。最終可能會要求修改數(shù)據(jù)庫結(jié)構(gòu)。 小心保留詞要保證你的字段名沒有和保留詞、數(shù)據(jù)庫系統(tǒng)或者常用訪問方法沖突，比如，最近我編寫的一個 ODBC 連接程序里有個表，其中就用了 DESC 作為說明字段名。 每個表中都應(yīng)該添加的 3 個有用的字段* dRecordCreationDate，在 VB 下默認(rèn)是 Now()，而在 SQL Server 下默認(rèn)為 GETDATE()* sRecordCreator，在 SQL Server 下默認(rèn)為 NOT NULL DEFAULT USER* nRecordVersion，記錄的版本標(biāo)記；有助于準(zhǔn)確說明記錄中出現(xiàn) null 數(shù)據(jù)或者丟失數(shù)據(jù)的原因 對地址和電話采用多個字段描述街道地址就短短一行記錄是不夠的。 不活躍或者不采用的指示符增加一個字段表示所在記錄是否在業(yè)務(wù)中不再活躍挺有用的。標(biāo)準(zhǔn)化有好幾種形式，但 Third Normal Form（3NF）通常被認(rèn)為在性能、擴(kuò)展性和數(shù)據(jù)完整性方面達(dá)到了最好平衡。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。有一份諸如 ER 圖表等最新文檔其重要性如何強調(diào)都不過分，這對表明表之間關(guān)系很有用，而數(shù)據(jù)字典則說明了每個字段的用途以及任何可能存在的別名。這樣做可以達(dá)到兩個目的：首先，你可以清楚地了解應(yīng)用設(shè)計在哪個地方應(yīng)該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。此外還要給表的別名定義簡單規(guī)則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結(jié)果還是組成 4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴 WORK_ 后面附上采用該表的應(yīng)用程序的名字。如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設(shè)計就是應(yīng)用中最重要的一部分。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。 獲取數(shù)據(jù)模式資源手冊正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。其中至少應(yīng)該包含每個字段的數(shù)據(jù)類型和在每個表內(nèi)的主外鍵。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，那么策略變更和維護(hù)都會方便得多。所以如果表出了問題重新產(chǎn)生非標(biāo)準(zhǔn)化的表是完全可能的。采用一般抽象術(shù)語來標(biāo)識“事物”的類別可以讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。這一問題從 Access 到 Oracle 數(shù)據(jù)庫都存在。 包含版本機制建議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本。這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的 SQL 語句可以寫成如下所示：Select * From Customer, Order Where cu_surname = MYNAME 。假如你總是在設(shè)計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。你得考慮數(shù)據(jù)庫的空間有多大，表如何進(jìn)行訪問，還有這些訪問是否主要用作讀寫。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。如果可選鍵真正有用，那就是達(dá)到了主鍵的水準(zhǔn)。當(dāng)你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設(shè)置一些標(biāo)記。 使用查找控制數(shù)據(jù)完整性的最佳方式就是限制用戶的選擇。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。根據(jù)需要用這些文件連接到主文件中的主表。不管你選擇哪種方式，總要