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