【正文】 數(shù)據(jù)的功能性。除非你的字段命名很冗長，否則字段名本身還不夠。假如需求源于維護數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。還有，不要索引memo/notes 字段而且不要索引大型文本字段 (許多字符 )，這樣做會讓你的索引占據(jù)大量的數(shù)據(jù)庫空間。 別忘了外鍵 大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建的主鍵字段。你要做 的無非是創(chuàng)建毫無價值的數(shù)據(jù)。如果可選鍵真正有用，那就是達到了主鍵的水準。這樣可以阻止使用數(shù)據(jù)庫的人不得不連接數(shù)據(jù)庫從而恰當?shù)倪^濾數(shù)據(jù)。 假如你有可選鍵，你可能進一步把它用做主鍵。而這一過程往往錯誤叢生所以應(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 還曾被用做系列號，當然盡管這么做是非法的。除了隱私原因以外，須知政府越來越趨向于不準許把 SSN 或 ID 用作除收入相關(guān)以外的其他目的， SSN 或 ID需要手工輸入。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。還有，不要索引 memo/note 字段，不要 索引大型字段 (有很多字符 )，這樣作會讓索引占用太多的存儲空間。你得考慮數(shù)據(jù)庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。作為一條規(guī)則，我通常對邏輯主鍵使用唯一的成組索引，對系統(tǒng)鍵 (作為存儲過程 )采用唯一的非成組索引，對任何外鍵列 [字段 ]采用非成組索引。 別忘了索引 索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)的最高效方式之一。 *避免使用復(fù)合鍵。 鍵設(shè)計 4原則 *為關(guān)聯(lián)字段創(chuàng)建外鍵。性能也會變壞。索 引將加快 SQL和報表生成器腳本的執(zhí)行速度。 采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當你擁有一致的鍵結(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ù)字段。當我從最開始設(shè)計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數(shù)據(jù)庫的運行速度。 第 3部分 選擇鍵和索引 數(shù)據(jù)采掘要預(yù)先計劃 我所在的某一客戶部門一度要處理 8萬多份聯(lián)系方式，同時填寫每個客戶的必要數(shù)據(jù) (這絕對不是小活 )。 這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的 SQL語句可以寫成如下所示： Select*From Customer,Order Where cu_surname=MYNAME； and cu_name_id=or_cust_name_id and or_quantity=1 在沒有這些前綴的情況下則寫成這個樣子 (用別名來區(qū)分 )： Select*From Customer,Order Where =MYNAME； and = and =1 第 1個 SQL語句沒少鍵入多少字符。 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ù)長。雖然你可以通過檢查新字段或者索引來確定數(shù)據(jù)庫結(jié)構(gòu)的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎 ?。時間一長，用戶的需求總是會改變的。 包含版本機制 建議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本。在調(diào)試程序時觸發(fā)器可能成為干擾。在關(guān)系數(shù)據(jù)庫里不要單獨刪除某一行；最好 采用清除數(shù)據(jù)程序而且要仔細維護索引整體性。 仔細選擇數(shù)字類型 在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了 ,767你就不能進行計算操作了。假如數(shù)據(jù)類型在一個表里是整數(shù)，那在另一個表里可就別變成字符型了。 保持字段名和類型的一致性 在命名字段并為其指定數(shù)據(jù)類型的時候一定要保證一致性。后果可想而知！ DESC 是 DESCENDING 縮寫后的保留詞。想想看，這種數(shù)據(jù)庫 /應(yīng)用程序能混到采用更強大數(shù)據(jù) 庫的那一天嗎 ?采用全部大寫而且包含下劃符的名字具有更好的可讀性 (CUSTOMER_DATA)，絕對不要在對象名的字符之間留空格。這一問題從 Access 到 Oracle 數(shù)據(jù)庫都存在?？傊捎眠B接字段的方式可以有效的隔離用戶應(yīng)用和開發(fā)人員界面。 我最常用的是在同一表中創(chuàng)建一個計算列 [字段 ]，通過它可以自動地連接標準化后的字段，這樣數(shù)據(jù)變動的時候它也跟著變。我覺得只有剛?cè)腴T的開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。非標準化和加速訪問之間的妥協(xié)是有一定意義的。 過分標準化可要小心，這樣做可能會導(dǎo)致性能上出現(xiàn)問題。 Address_Line Address_Line2和 Address_Line3 可以提供更大的靈活性。 數(shù)據(jù)重復(fù)需要采用分立的數(shù)據(jù)表 如果你發(fā)現(xiàn)自己在重復(fù)輸入數(shù)據(jù)，請創(chuàng)建新表和新的關(guān)系。 采用一般抽象術(shù)語來標識 事物 的類別可以讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。同樣的， ORGANIZATION 也可能是 MyCompany、 MyDepartment、Competitor、 Hospital、 Warehouse、 Government 等。開始的時候采用一般術(shù)語的主要原因在于所有的具體 用戶都能對抽象事物具體化。 采用常用實體命名機構(gòu)數(shù)據(jù) 組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如： PERSON、 ORGANIZATION、ADDRESS 和 PHONE等等。這樣，你的PERSON_TYPE 表就包含了所有 PERSON 的可能類型，比如 Associate、 Engineer、Director、 CIO或者 CEO 等。 使用角色實體定義屬于某類別的列 [字段 ] 在需要對屬于特定類別或者具有特定角 色的事物做定義時，可以用角色實體來創(chuàng)建特定的時間關(guān)聯(lián)關(guān)系，從而可以實現(xiàn)自我文檔化。不管是客戶、員工還是其他什么人，這樣做都能有助于再運行查詢的時候過濾活躍或者不活躍狀態(tài)。所以如果表出了問題重新產(chǎn)生非標準化的表是完全可能的。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標準化當作當然的設(shè)計理念。 為了效率的緣故，對表不進行標準化有時也是必要的，這樣的例子很多。 更高層次的標準化也有，但更標準是否就一定更好呢 ?答案是不一定。比方說，某個存放客戶及其有關(guān)定單的 3NF 數(shù)據(jù)庫就可能有兩個表： Customer 和 Order。 *表內(nèi)不應(yīng)該存儲依賴于其他鍵的非鍵信息。簡單來說， 3NF規(guī)定： *表內(nèi)的每一個值都只能被表達一次。 標準化不能過頭 對那些不熟悉標準化一詞 (normalization)的人而言，標準化可以保證表內(nèi)的字段都是最基礎(chǔ)的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，那么策略變更和維護都會方便得多。比方說，假如你的用戶界面要訪問外部數(shù)據(jù)源 (文件、 XML 文檔、其他數(shù)據(jù)庫等 )，你不妨把相應(yīng)的連接和路徑信息存儲在用戶界面支持表里。時間標記對查找數(shù)據(jù)問題的原因、按日期重新處理 /重 載數(shù)據(jù)和清除舊數(shù)據(jù)特別有用。 采用前綴命名 如果多個表里有好多同一類型的字段 (比如 FirstName)