數(shù)據(jù)庫設(shè)計經(jīng)驗談-文庫吧
2025-07-20 16:50 本頁面
【正文】 式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫設(shè)計中幾乎不可能出現(xiàn)大的問題。模式不必弄的很復(fù)雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關(guān)系今后能產(chǎn)生效益。從輸入輸出下手在定義數(shù)據(jù)庫表和字段需求（輸入）時，首先應(yīng)檢查現(xiàn)有的或者已經(jīng)設(shè)計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。報表技巧要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創(chuàng)建總結(jié)表。系統(tǒng)生成的主鍵在報表中很難管理。用戶在具有系統(tǒng)生成主鍵的表內(nèi)用副鍵進行檢索往往會返回許多重復(fù)數(shù)據(jù)。這樣的檢索性能比較低而且容易引起混亂。理解客戶需求看起來這應(yīng)該是顯而易見的事，但需求就是來自客戶（這里要從內(nèi)部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經(jīng)常詢問客戶保證其需求仍然在開發(fā)的目的之中。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導(dǎo)致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。第2部分設(shè)計表和字段檢查各種變化我在設(shè)計數(shù)據(jù)庫的時候會考慮到哪些數(shù)據(jù)字段將來可能會發(fā)生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結(jié)婚后從夫姓等）。所以，在建立系統(tǒng)存儲客戶信息時，我傾向于在單獨的一個數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。采用有意義的字段名有一回我參加開發(fā)過一個項目，其中有從其他程序員那里繼承的程序，那個程序員喜歡用屏幕上顯示數(shù)據(jù)指示用語命名字段，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名采用了匈牙利命名和控制序號的組合形式，比如cbotxttxt2_b等等。除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。當然，也別做過頭了，比如Customer_Shipping_Address_Street_Line_1，雖然很富有說明性，但沒人愿意鍵入這么長的名字，具體尺度就在你的把握中。采用前綴命名如果多個表里有好多同一類型的字段（比如FirstName），你不妨用特定表的前綴（比如CusLastName）來幫助你標識字段。時效性數(shù)據(jù)應(yīng)包括“最近更新日期/時間”字段。時間標記對查找數(shù)據(jù)問題的原因、按日期重新處理/重載數(shù)據(jù)和清除舊數(shù)據(jù)特別有用。標準化和數(shù)據(jù)驅(qū)動數(shù)據(jù)的標準化不僅方便了自己而且也方便了其他人。比方說，假如你的用戶界面要訪問外部數(shù)據(jù)源（文件、XML文檔、其他數(shù)據(jù)庫等），你不妨把相應(yīng)的連接和路徑信息存儲在用戶界面支持表里。還有，如果用戶界面執(zhí)行工作流之類的任務(wù)（發(fā)送郵件、打印信箋、修改記錄狀態(tài)等），那么產(chǎn)生工作流的數(shù)據(jù)也可以存放在數(shù)據(jù)庫里。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動而非硬編碼的方式，那么策略變更和維護都會方便得多。事實上，如果過程是數(shù)據(jù)驅(qū)動的，你就可以把相當大的責任推給用戶，由用戶來維護自己的工作流過程。標準化不能過頭對那些不熟悉標準化一詞（normalization）的人而言，標準化可以保證表內(nèi)的字段都是最基礎(chǔ)的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。標準化有好幾種形式，但ThirdNormalForm（3NF）通常被認為在性能、擴展性和數(shù)據(jù)完整性方面達到了最好平衡。簡單來說，3NF規(guī)定：*表內(nèi)的每一個值都只能被表達一次。*表內(nèi)的每一行都應(yīng)該被唯一的標識（有唯一鍵）。*表內(nèi)不應(yīng)該存儲依賴于其他鍵的非鍵信息。遵守3NF標準的數(shù)據(jù)庫具有以下特點：有一組表專門存放通過鍵連接起來的關(guān)聯(lián)數(shù)據(jù)。比方說，某個存放客戶及其有關(guān)定單的3NF數(shù)據(jù)庫就可能有兩個表：Customer和Order。Order表不包含定單關(guān)聯(lián)客戶的任何信息，但表內(nèi)會存放一個鍵值，該鍵指向Customer表里包含該客戶信息的那一行。更高層次的標準化也有，但更標準是否就一定更好呢？答案是不一定。事實上，對某些項目來說，甚至就連3NF都可能給數(shù)據(jù)庫引入太高的復(fù)雜性。為了效率的緣故，對表不進行標準化有時也是必要的，這樣的例子很多。曾經(jīng)有個開發(fā)餐飲分析軟件的活就是用非標準化表把查詢時間從平均40秒降低到了兩秒左右。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標準化當作當然的設(shè)計理念。而具體的操作不過是一種派生。所以如果表出了問題重新產(chǎn)生非標準化的表是完全可能的。MicrosoftVisualFoxPro報表技巧如果你正在使用MicrosoftVisualFoxPro，你可以用對用戶友好的字段名來代替編號的名稱：比如用CustomerName代替txtCNaM。這樣，當你用向?qū)С绦騕Wizards，臺灣人稱為‘精靈’]創(chuàng)建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。不活躍或者不采用的指示符增加一個字段表示所在記錄是否在業(yè)務(wù)中不再活躍挺有用的。不管是客戶、員工還是其他什么人，這樣做都能有助于再運行查詢的時候過濾活躍或者不活躍狀態(tài)。同時還消除了新用戶在采用數(shù)據(jù)時所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時候可以起到一定的防范作用。使用角色實體定義屬于某類別的列[字段]在需要對屬于特定類別或者具有特定角色的事物做定義時，可以用角色實體來創(chuàng)建特定的時間關(guān)聯(lián)關(guān)系，從而可以實現(xiàn)自我文檔化。這里的含義不是讓PERSON實體帶有Title字段，而是說，為什么不用PERSON實體和PERSON_TYPE實體來描述人員呢？比方說，當JohnSmith,Engineer提升為JohnSmith,Director乃至最后爬到JohnSmith,CIO的高位，而所有你要做的不過是改變兩個表PERSON和PERSON_TYPE之間關(guān)系的鍵值，同時增加一個日期/時間字段來知道變化是何時發(fā)生的。這樣，你的PERSON_TYPE表就包含了所有PERSON的可能類型，比如A
范文總結(jié)相關(guān)推薦
鄂ICP備17016276號-1