【正文】 用戶不必了解數(shù)據(jù)庫是否是分布式的。但是必須有一種語言，它的語句可以表示為具有嚴格語法規(guī)定的字符串，并能全面的支持以下功能：數(shù)據(jù)定義，視圖定義，數(shù)據(jù)操作 ，完整約束，授權(quán)，事物控制。t worryifsomeof these items are confusingto you,as we move further through this newsletter series we will fillin the 12 條規(guī)則的中文由 SilentKiller 翻譯，不保證全部正確。最重要的是，讓用戶進行測試并且同用戶一道保證你選擇的數(shù)據(jù)類型滿足商業(yè)要求。但是用戶通常都用英語進行思考而不是編碼。 取決于你使用的數(shù)據(jù)庫系統(tǒng)，可能有一些軟件會給你一些供你很快上手的文檔。數(shù)據(jù)庫不只是一個存放數(shù)據(jù)的地方，它也是簡化編碼之地。 關(guān)系 如果兩個實體之間存在多對一關(guān)系，而且還有可能轉(zhuǎn)化為多對多關(guān)系，那么你最好一開始就設(shè)置成多對多關(guān)系。 分布式數(shù)據(jù)系統(tǒng) 對分布式系統(tǒng)而言，在你決定是否在各個站點復(fù)制所有數(shù)據(jù)還是把數(shù)據(jù)保存在一個地方之前應(yīng)該估計一下未來 5年或者 10年的數(shù)據(jù)量。 第 4部分 保證數(shù)據(jù)的完整性 用約束而非商務(wù)規(guī)則強制數(shù)據(jù)完整性 如果你按照商務(wù)規(guī)則來處理需求，那么你應(yīng)當檢查商務(wù)層次 /用戶界面：如果商務(wù)規(guī)則以后發(fā)生變化，那么只需 要進行更新即可。在嚴格控制域表的數(shù)據(jù)庫上，這種負載是比較醒目的。 假如你在 Customer 表里修改了 CustomerID，那么你必須找出 Order 表中的所有相關(guān)記錄對其進行修改。當用戶在輸入數(shù)據(jù)之后直到保存記錄才發(fā)現(xiàn)系統(tǒng)出了問題他們該怎么想 ?刪除重建 ?假如記錄不可重建是否讓用戶走開 ? *提出一些檢測和糾正鍵沖突的方法。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個 記錄然后從頭開始。不過，索引就象是鹽，太多了菜就咸了。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。 使用系統(tǒng)生成的主鍵 這類同技巧 1，但我覺得有必要在這里重復(fù)提醒大家。 然后我意識到特定的組查詢和信息采掘既不準確速度也不快。舉個簡單的例子，假設(shè)有兩個表： Customer 和 Order。 給文本字段留足余量 ID 類型的文本字段，比如客戶 ID 或定單號等等都應(yīng)該設(shè)置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。 避免使用觸發(fā)器觸發(fā)器的功能通常可以用其他方式實現(xiàn)。表里的一個SELECT*語句倒是能用，但我得到的卻是一大堆毫無用處的信息。不過，這樣做在采用建模軟件時得很機靈才行。還有，電話號碼和 郵件地址最好擁有自己的數(shù)據(jù)表，其間具有自身的類型和標記類別。 有了這些抽象表示，你就可以在第 2 級標識中采用自己的特殊名稱，比如，PERSON 可能是 Employee、 Spouse、 Patient、 Client、 Customer、 Vendor 或者Teacher 等。同時還消除了新用戶在采用數(shù)據(jù)時所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時候可以起到一定的防范作用。事實上，對某些項目來說，甚至就連 3NF都可能給數(shù)據(jù)庫引入太高的復(fù)雜性。標準化有好幾種形式，但 Third Normal Form(3NF)通常被認為在性能、擴展性和數(shù)據(jù)完整性方面達到了最好平衡。 時效性數(shù)據(jù)應(yīng)包括 最近更新日期 /時間 字段。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。 報表技巧 要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表 ?時間間隔是每天、每周、每月、每個季度還是每年 ?如果需要的話還可以考慮創(chuàng)建總結(jié)表。 有一份諸如 ER 圖表等最新文檔 其重要性如何強調(diào)都不過分，這對表明表之間關(guān)系很有用，而數(shù)據(jù)字典則說明了每個字段的用途以及任何可能存在的別名。 一旦你認為你已經(jīng)明確了業(yè)務(wù)內(nèi)容，你最好同客戶進行一次系 統(tǒng)的交流。這樣做可以達到兩個目的：首先，你可以清楚地了解應(yīng)用設(shè)計在哪個地方應(yīng)該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫的不同組成部分，至少你應(yīng)該在這些對象名字的開頭用 Table、 Query 或者 Report 等前綴加以區(qū)別。此外還要給表的別名定義簡單規(guī)則 (比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4個字母長的別名；如果表的名字由 3個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結(jié)果還是組成 4字母長的別名，其余依次類推 )對工作用表來說，表名可以加上前綴 WORK_后 面附上采用該表的應(yīng)用程序的名字。 第 5部分 各種小技巧 不包括在以上 4個部分中的其他技巧，五花八門，有了它們希望你的數(shù)據(jù)庫開發(fā)工作會更輕松一些。 如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設(shè)計就是應(yīng)用中最重要的一部分。 第 2部分 設(shè)計數(shù)據(jù)庫表 總共 24 個指南性技巧，涵蓋表內(nèi)字段設(shè)計以及應(yīng)該避免的常見問題等。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。還有，日期列 [字段 ]最好以 D_作為名字打頭。 獲取數(shù)據(jù)模式資源手冊 正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由 Len Silverston、 和 Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。 了解你的業(yè)務(wù) 在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER(實體關(guān)系 )模式中加入哪怕一個數(shù)據(jù)表 (怎么，你還沒有模式 ?那請你參看技巧 9)。其中至少應(yīng)該包含每個字段的數(shù)據(jù)類型和在每個表內(nèi)的主外鍵。只是要保證其上的邏輯關(guān)系今后能產(chǎn)生效益。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。 除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，那么策略變更和維護都會方便得多。比方說，某個存放客戶及其有關(guān)定單的 3NF 數(shù)據(jù)庫就可能有兩個表： Customer 和 Order。所以如果表出了問題重新產(chǎn)生非標準化的表是完全可能的。 采用常用實體命名機構(gòu)數(shù)據(jù) 組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如： PERSON、 ORGANIZATION、ADDRESS 和 PHONE等等。 數(shù)據(jù)重復(fù)需要采用分立的數(shù)據(jù)表 如果你發(fā)現(xiàn)自己在重復(fù)輸入數(shù)據(jù)，請創(chuàng)建新表和新的關(guān)系。我覺得只有剛?cè)腴T的開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。想想看，這種數(shù)據(jù)庫 /應(yīng)用程序能混到采用更強大數(shù)據(jù) 庫的那一天嗎 ?采用全部大寫而且包含下劃符的名字具有更好的可讀性 (CUSTOMER_DATA)，絕對不要在對象名的字符之間留空格。 仔細選擇數(shù)字類型 在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了 ,767你就不能進行計算操作了。時間一長，用戶的需求總是會改變的。身份證的號碼從 15位變成 18 位就是最好和最慘痛的例子。 第 3部分 選擇鍵和索引 數(shù)據(jù)采掘要預(yù)先計劃 我所在的某一客戶部門一度要處理 8萬多份聯(lián)系方式，同時填寫每個客戶的必要數(shù)據(jù) (這絕對不是小活 )。在 DW 環(huán)境下，你要考慮銷售部門是如何組織銷售活動的。索 引將加快 SQL和報表生成器腳本的執(zhí)行速度。 別忘了索引 索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)的最高效方式之一。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。通常的情況下不要選擇用戶可編輯的字段作為鍵。比如， Customer 表有一個主 鍵 CustomerID，而客戶的定單則存放在另一個表里。 假如你有可選鍵，你可能進一步把它用做主鍵。 別忘了外鍵 大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建的主鍵字段。這不但包括通過標準化實現(xiàn)的完整性而且還包括數(shù)據(jù)的功能性。 強制指示完整性 (參照完整性 ?) 沒有好辦法能在有害數(shù)據(jù)進入數(shù)據(jù)庫之后消除它，所以你應(yīng)該在它進 入數(shù)據(jù)庫之前將其剔除。采用可以發(fā)布給用戶 /開發(fā)人員的數(shù)據(jù)字典實現(xiàn)方便的數(shù)據(jù)識別同時保證對數(shù)據(jù)源文檔化。 第 5部分 各種小技巧 文檔、文檔、文檔 對所有的快捷方式、命名規(guī)范、限制和函數(shù)都要編制文檔。 使用常用英語 (或者其他任何語言 )而不要使用編碼 為什么我們經(jīng)常采用編碼 (比如 9935A 可能是 39。我常在這個表里存放數(shù)據(jù)庫當前版本、最近檢查 /修復(fù) (對 FoxPro)、關(guān)聯(lián)設(shè)計文檔的名稱、