cvqaaa數(shù)據(jù)庫設(shè)計(存儲版)
【正文】 命名機構(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，那么，如果總額超過了 $32,767 你就不能進行計算操作了。時間一長，用戶的需求總是會改變的。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。and = and = 1第 1 個 SQL 語句沒少鍵入多少字符。采用后者作為主字段，數(shù)據(jù)庫更新后重新索引和檢索就快多了。采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當(dāng)你擁有一致的鍵結(jié)構(gòu)時，找到邏輯缺陷很容易。* 避免使用復(fù)合鍵。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把 SSN 或 ID 刪除。所以還是重提一句老話：你的設(shè)計要適應(yīng)用戶而不是讓用戶來適應(yīng)你的設(shè)計。而這一過程往往錯誤叢生所以應(yīng)該盡量避免。你要做的無非是創(chuàng)建毫無價值的數(shù)據(jù)。除非你的字段命名很冗長，否則字段名本身還不夠。為了進行這種數(shù)據(jù)傳輸，請寫下你自己的批處理或者調(diào)度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數(shù)據(jù)。這樣做還等于在處理數(shù)據(jù)庫變更時給你提供了更多的自由。這樣將減少鍵入代碼的錯誤和誤解同時提供數(shù)據(jù)的一致性。不管你選擇哪種方式，總要對你的數(shù)據(jù)庫文檔化，或者在數(shù)據(jù)庫自身的內(nèi)部或者單獨建立文檔。我常在這個表里存放數(shù)據(jù)庫當(dāng)前版本、最近檢查/修復(fù)（對 FoxPro）、關(guān)聯(lián)設(shè)計文檔的名稱、客戶等信息。根據(jù)需要用這些文件連接到主文件中的主表。換句話說，針對每一種最終表達數(shù)據(jù)的原型應(yīng)用，保證你檢查了數(shù)據(jù)模型并且查看如何取出數(shù)據(jù)。假如你需要編碼，那你可以在編碼旁附上用戶知道的英語。你可能希望先開始在說，然后獲得越來越多的細節(jié)。 使用查找控制數(shù)據(jù)完整性的最佳方式就是限制用戶的選擇。從現(xiàn)有的多對一關(guān)系轉(zhuǎn)變?yōu)槎鄬Χ嚓P(guān)系比一開始就是多對多關(guān)系要難得多。當(dāng)你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設(shè)置一些標(biāo)記。假如需求源于維護數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。如果可選鍵真正有用，那就是達到了主鍵的水準。否則，有些定單就會不屬于任何客戶——數(shù)據(jù)庫的完整性就算完蛋了。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當(dāng)然盡管這么做是非法的。你得考慮數(shù)據(jù)庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。 鍵設(shè)計 4 原則* 為關(guān)聯(lián)字段創(chuàng)建外鍵。假如你總是在設(shè)計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。結(jié)果只好在主索引中重建而且合并了數(shù)據(jù)字段。這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的 SQL 語句可以寫成如下所示：Select * From Customer, Order Where cu_surname = MYNAME 。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長 3 個字符在有 1 百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù) 3MB 的空間。 包含版本機制建議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本。假如數(shù)據(jù)類型在一個表里是整數(shù)，那在另一個表里可就別變成字符型了。這一問題從 Access 到 Oracle 數(shù)據(jù)庫都存在。非標(biāo)準化和加速訪問之間的妥協(xié)是有一定意義的。采用一般抽象術(shù)語來標(biāo)識“事物”的類別可以讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。這樣，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能類型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。所以如果表出了問題重新產(chǎn)生非標(biāo)準化的表是完全可能的。比方說，某個存放客戶及其有關(guān)定單的 3NF 數(shù)據(jù)庫就可能有兩個表：Customer 和 Order。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，那么策略變更和維護都會方便得多。除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。只是要保證其上的邏輯關(guān)系今后能產(chǎn)生效益。其中至少應(yīng)該包含每個字段的數(shù)據(jù)類型和在每個表內(nèi)的主外鍵。 了解你的業(yè)務(wù)在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER（實體關(guān)系）模式中加入哪怕一個數(shù)據(jù)表（怎么，你還沒有模式？那請你參看技巧 9）。 獲取數(shù)據(jù)模式資源手冊正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。還有，日期列[字段]最好以 D_ 作為名字打頭。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。 第 2 部分 設(shè)計數(shù)據(jù)庫表總共 24 個指南性技巧，涵蓋表內(nèi)字段設(shè)計以及應(yīng)該避免的常見問題等。如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設(shè)計就是應(yīng)用中最重要的一部分。 第 5 部分 各種小技巧不包括在以上 4 個部分中的其他技巧，五花八門，有了它們希望你的數(shù)據(jù)庫開發(fā)工作會更輕松一些。此外還要給表的別名定義簡單規(guī)則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結(jié)果還是組成 4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴 WORK_ 后面附上采用該表的應(yīng)用程序的名字。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫的不同組成部分，至少你應(yīng)該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區(qū)別。這樣做可以達到兩個目的：首先，你可以清楚地了解應(yīng)用設(shè)計在哪個地方應(yīng)
研究報告相關(guān)推薦
鄂ICP備17016276號-1