【正文】 這一措施簡化了用戶和組權(quán)限的分配，而且有利于應(yīng)用程序函數(shù)（存儲過程）的分組和劃分，從而在程序必須修改的時候易于管理。根據(jù)需要用這些文件連接到主文件中的主表。換句話說，針對每一種最終表達(dá)數(shù)據(jù)的原型應(yīng)用，保證你檢查了數(shù)據(jù)模型并且查看如何取出數(shù)據(jù)。測試需要在把新數(shù)據(jù)庫投入實際服務(wù)之前完成。 測試、測試、反復(fù)測試建立或者修訂數(shù)據(jù)庫之后，必須用用戶新輸入的數(shù)據(jù)測試數(shù)據(jù)字段。我常在這個表里存放數(shù)據(jù)庫當(dāng)前版本、最近檢查/修復(fù)（對 FoxPro）、關(guān)聯(lián)設(shè)計文檔的名稱、客戶等信息。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。工作 5 年的會計或許知道 4XF788Q 是什么東西，但新來的可就不一定了。 使用常用英語（或者其他任何語言）而不要使用編碼為什么我們經(jīng)常采用編碼（比如 9935A 可能是‘青島啤酒’的供應(yīng)代碼，4XF788Q 可能是帳目編碼）？理由很多。不管你選擇哪種方式，總要對你的數(shù)據(jù)庫文檔化，或者在數(shù)據(jù)庫自身的內(nèi)部或者單獨建立文檔。你可能希望先開始在說，然后獲得越來越多的細(xì)節(jié)。是的，這有點費事，但從長遠(yuǎn)來看，這樣做對開發(fā)、支持和跟蹤修改非常有用。 第 5 部分 各種小技巧文檔、文檔、文檔對所有的快捷方式、命名規(guī)范、限制和函數(shù)都要編制文檔。這樣將減少鍵入代碼的錯誤和誤解同時提供數(shù)據(jù)的一致性。 使用查找控制數(shù)據(jù)完整性的最佳方式就是限制用戶的選擇。 用存儲過程讓系統(tǒng)做重活解決了許多麻煩來產(chǎn)生一個具有高度完整性的數(shù)據(jù)庫解決方案之后，我決定封裝一些關(guān)聯(lián)表的功能組，提供一整套常規(guī)的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發(fā)。采用可以發(fā)布給用戶/開發(fā)人員的數(shù)據(jù)字典實現(xiàn)方便的數(shù)據(jù)識別同時保證對數(shù)據(jù)源文檔化。這樣做還等于在處理數(shù)據(jù)庫變更時給你提供了更多的自由。從現(xiàn)有的多對一關(guān)系轉(zhuǎn)變?yōu)槎鄬Χ嚓P(guān)系比一開始就是多對多關(guān)系要難得多。這樣可以保持?jǐn)?shù)據(jù)的清潔而能迫使開發(fā)人員投入更多的時間處理錯誤條件。 強制指示完整性(參照完整性?)沒有好辦法能在有害數(shù)據(jù)進(jìn)入數(shù)據(jù)庫之后消除它，所以你應(yīng)該在它進(jìn)入數(shù)據(jù)庫之前將其剔除。為了進(jìn)行這種數(shù)據(jù)傳輸，請寫下你自己的批處理或者調(diào)度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數(shù)據(jù)。當(dāng)你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設(shè)置一些標(biāo)記。不要依賴于商務(wù)層保證數(shù)據(jù)完整性；它不能保證表之間（外鍵）的完整性所以不能強加于其他完整性規(guī)則之上。這不但包括通過標(biāo)準(zhǔn)化實現(xiàn)的完整性而且還包括數(shù)據(jù)的功能性。除非你的字段命名很冗長，否則字段名本身還不夠。假如需求源于維護(hù)數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。還有，不要索引 memo/notes 字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引占據(jù)大量的數(shù)據(jù)庫空間。 別忘了外鍵大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建的主鍵字段。你要做的無非是創(chuàng)建毫無價值的數(shù)據(jù)。如果可選鍵真正有用，那就是達(dá)到了主鍵的水準(zhǔn)。這樣可以阻止使用數(shù)據(jù)庫的人不得不連接數(shù)據(jù)庫從而恰當(dāng)?shù)倪^濾數(shù)據(jù)。假如你有可選鍵，你可能進(jìn)一步把它用做主鍵。而這一過程往往錯誤叢生所以應(yīng)該盡量避免。否則，有些定單就會不屬于任何客戶——數(shù)據(jù)庫的完整性就算完蛋了。不管你選擇哪種鍵設(shè)置，你都需要在 Order 表中存放 CustomerID 來保證你可以給下定單的用戶找到其定單記錄。比如，Customer 表有一個主鍵 CustomerID，而客戶的定單則存放在另一個表里。所以還是重提一句老話：你的設(shè)計要適應(yīng)用戶而不是讓用戶來適應(yīng)你的設(shè)計。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。假如你這么做了，你可能會發(fā)現(xiàn)你的應(yīng)用程序在商務(wù)需求突然發(fā)生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。通常的情況下不要選擇用戶可編輯的字段作為鍵。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把 SSN 或 ID 刪除。我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當(dāng)然盡管這么做是非法的。除了隱私原因以外，須知政府越來越趨向于不準(zhǔn)許把 SSN 或 ID 用作除收入相關(guān)以外的其他目的，SSN 或 ID 需要手工輸入。對這些插入和刪除操作的索引維護(hù)可能比掃描表空間消耗更多的時間。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。你得考慮數(shù)據(jù)庫的空間有多大，表如何進(jìn)行訪問，還有這些訪問是否主要用作讀寫。作為一條規(guī)則，我通常對邏輯主鍵使用唯一的成組索引，對系統(tǒng)鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列[字段]采用非成組索引。 別忘了索引索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)的最高效方式之一。* 避免使用復(fù)合鍵。 鍵設(shè)計 4 原則* 為關(guān)聯(lián)字段創(chuàng)建外鍵。性能也會變壞。索引將加快 SQL 和報表生成器腳本的執(zhí)行速度。采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當(dāng)你擁有一致的鍵結(jié)構(gòu)時，找到邏輯缺陷很容易。假如你總是在設(shè)計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。這里設(shè)計人員或者數(shù)據(jù)庫工作人員應(yīng)該分析數(shù)據(jù)庫結(jié)構(gòu)從而確定出性能和正確輸出之間的最佳條件。在 DW 環(huán)境下，你要考慮銷售部門是如何組織銷售活動的。采用后者作為主字段，數(shù)據(jù)庫更新后重新索引和檢索就快多了。結(jié)果只好在主索引中重建而且合并了數(shù)據(jù)字段。當(dāng)我從最開始設(shè)計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數(shù)據(jù)庫的運行速度。 第 3 部分 選擇鍵和索引數(shù)據(jù)采掘要預(yù)先計劃我所在的某一客戶部門一度要處理 8 萬多份聯(lián)系方式，同時填寫每個客戶的必要數(shù)據(jù)（這絕對不是小活）。and = and = 1第 1 個 SQL 語句沒少鍵入多少字符。這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的 SQL 語句可以寫成如下所示：Select * From Customer, Order Where cu_surname = MYNAME 。Customer 表的前綴是 cu_，所以該表內(nèi)的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，后者把公共列[字段]名同某些數(shù)據(jù)庫聯(lián)系起來，不過就連這些工具有時不也連接錯誤嘛。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長 3 個字符在有 1 百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù) 3MB 的空間。比方說，假設(shè)你的客戶 ID 為 10 位數(shù)長。雖然你可以通