【正文】 ，數(shù)據(jù)庫更新后重新索引和檢索就快多了。采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。還有，不要索引memo/note字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把SSN或ID刪除。所以還是重提一句老話：你的設計要適應用戶而不是讓用戶來適應你的設計。而這一過程往往錯誤叢生所以應該盡量避免。你要做的無非是創(chuàng)建毫無價值的數(shù)據(jù)。除非你的字段命名很冗長，否則字段名本身還不夠。為了進行這種數(shù)據(jù)傳輸，請寫下你自己的批處理或者調(diào)度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數(shù)據(jù)。這樣做還等于在處理數(shù)據(jù)庫變更時給你提供了更多的自由。這樣將減少鍵入代碼的錯誤和誤解同時提供數(shù)據(jù)的一致性。不管你選擇哪種方式，總要對你的數(shù)據(jù)庫文檔化，或者在數(shù)據(jù)庫自身的內(nèi)部或者單獨建立文檔。我常在這個表里存放數(shù)據(jù)庫當前版本、最近檢查/修復（對FoxPro）、關聯(lián)設計文檔的名稱、客戶等信息。根據(jù)需要用這些文件連接到主文件中的主表。換句話說，針對每一種最終表達數(shù)據(jù)的原型應用，保證你檢查了數(shù)據(jù)模型并且查看如何取出數(shù)據(jù)。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。你可能希望先開始在說，然后獲得越來越多的細節(jié)。使用查找控制數(shù)據(jù)完整性的最佳方式就是限制用戶的選擇。從現(xiàn)有的多對一關系轉(zhuǎn)變?yōu)槎鄬Χ嚓P系比一開始就是多對多關系要難得多。當你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設置一些標記。假如需求源于維護數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。如果可選鍵真正有用，那就是達到了主鍵的水準。否則，有些定單就會不屬于任何客戶——數(shù)據(jù)庫的完整性就算完蛋了。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。我在破解他人的程序時候，我看到很多人把SSN或ID還曾被用做系列號，當然盡管這么做是非法的。你得考慮數(shù)據(jù)庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。鍵設計4原則。假如你總是在設計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。結果只好在主索引中重建而且合并了數(shù)據(jù)字段。這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的SQL語句可以寫成如下所示：Select*FromCustomer,OrderWherecu_surname=MYNAME。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長3個字符在有1百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù)3MB的空間。假如你確實需要采用觸發(fā)器，你最好集中對它文檔化。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。提防大小寫混用的對象名和特殊字符過去最令我惱火的事情之一就是數(shù)據(jù)庫里有大小寫混用的對象名，比如CustomerData。雖然地址和電話表分離通?？梢赃_到最佳狀態(tài)，但是如果需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如Customer等）更為妥當些。最后ADDRESS可以具體為Site、Location、Home、Work、Client、Vendor、Corporate和FieldOffice等。這里的含義不是讓PERSON實體帶有Title字段，而是說，為什么不用PERSON實體和PERSON_TYPE實體來描述人員呢？比方說，當JohnSmith,Engineer提升為JohnSmith,Director乃至最后爬到JohnSmith,CIO的高位，而所有你要做的不過是改變兩個表PERSON和PERSON_TYPE之間關系的鍵值，同時增加一個日期/時間字段來知道變化是何時發(fā)生的。而具體的操作不過是一種派生。遵守3NF標準的數(shù)據(jù)庫具有以下特點：有一組表專門存放通過鍵連接起來的關聯(lián)數(shù)據(jù)。還有，如果用戶界面執(zhí)行工作流之類的任務（發(fā)送郵件、打印信箋、修改記錄狀態(tài)等），那么產(chǎn)生工作流的數(shù)據(jù)也可以存放在數(shù)據(jù)庫里。采用有意義的字段名有一回我參加開發(fā)過一個項目，其中有從其他程序員那里繼承的程序，那個程序員喜歡用屏幕上顯示數(shù)據(jù)指示用語命名字段，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名采用了匈牙利命名和控制序號的組合形式，比如cbotxttxt2_b等等。理解客戶需求看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內(nèi)部和外部客戶的角度考慮）。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。創(chuàng)建數(shù)據(jù)字典和ER圖表一定要花點時間創(chuàng)建ER圖表和數(shù)據(jù)字典。隨著大量的CASE工具不斷涌現(xiàn)出來，你的設計也可以達到相當高的邏輯水準，你通?？梢詮恼w上更好地了解數(shù)據(jù)庫設計所需要的方方面面。獲取數(shù)據(jù)模式資源手冊正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由LenSilverston、是一本值得擁有的最佳數(shù)據(jù)建模圖書。還有，日期列[字段]最好以D_作為名字打頭。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。第2部分設計數(shù)據(jù)庫表總共24個指南性技巧，涵蓋表內(nèi)字段設計以及應該避免的常見問題等。如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設計就是應用中最重要的一部分。第5部分各種小技巧不包括在以上4個部分中的其他技巧，五花八門，有了它們希望你的數(shù)據(jù)庫開發(fā)工作會更輕松一些。此外還要給表的別名定義簡單規(guī)則（比方說，如果表名是一個單詞，別名就取單詞的前4個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4個字母長的別名；如果表的名字由3個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結果還是組成4字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴WORK_后面附上采用該表的應用程序的名字。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫的不同組成部分，至少你應該在這些對象名字的開頭用Table、Query或者Report等前綴加以區(qū)別。暢想未來，但不可忘了過去的教訓我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓