|
第2 部分— 設(shè)計(jì)表和字段 1. 檢查各種變化 我在設(shè)計(jì)數(shù)據(jù)庫的時(shí)候會(huì)考慮到哪些數(shù)據(jù)字段將來可能會(huì)發(fā)生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結(jié)婚后從夫姓等）。所以，在建立系統(tǒng)存儲客戶信息時(shí)，我傾向于在單獨(dú)的一個(gè)數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。 2. 采用有意義的字段名 有一回我參加開發(fā)過一個(gè)項(xiàng)目，其中有從其他程序員那里繼承的程序，那個(gè)程序員喜歡用屏幕上顯示數(shù)據(jù)指示用語命名字段，這也不賴，但不幸的是，她還喜歡用一些奇怪的命名法，其命名采用了匈牙利命名和控制序號的組合形式，比如cbo1、txt2、txt2_b 等等。 除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。當(dāng)然，也別做過頭了，比如Customer_Shipping_Address_Street_Line_1 I 雖然很富有說明性，但沒人愿意鍵入這么長的名字，具體尺度就在你的把握中。 3. 采用前綴命名 如果多個(gè)表里有好多同一類型的字段（比如FirstName），你不妨用特定表的前綴（比如CusLastName）來幫助你標(biāo)識字段。 時(shí)效性數(shù)據(jù)應(yīng)包括“最近更新日期/時(shí)間”字段。時(shí)間標(biāo)記對查找數(shù)據(jù)問題的原因、按日期重新處理/重載數(shù)據(jù)和清除舊數(shù)據(jù)特別有用。 5. 標(biāo)準(zhǔn)化和數(shù)據(jù)驅(qū)動(dòng) 數(shù)據(jù)的標(biāo)準(zhǔn)化不僅方便了自己而且也方便了其他人。比方說，假如你的用戶界面要訪問外部數(shù)據(jù)源（文件、XML 文檔、其他數(shù)據(jù)庫等），你不妨把相應(yīng)的連接和路徑信息存儲在用戶界面支持表里。還有，如果用戶界面執(zhí)行工作流之類的任務(wù)（發(fā)送郵件、打印信箋、修改記錄狀態(tài)等），那么產(chǎn)生工作流的數(shù)據(jù)也可以存放在數(shù)據(jù)庫里。預(yù)先安排總需要付出努力，但如果這些過程采用數(shù)據(jù)驅(qū)動(dòng)而非硬編碼的方式，那么策略變更和維護(hù)都會(huì)方便得多。事實(shí)上，如果過程是數(shù)據(jù)驅(qū)動(dòng)的，你就可以把相當(dāng)大的責(zé)任推給用戶，由用戶來維護(hù)自己的工作流過程。 6. 標(biāo)準(zhǔn)化不能過頭 對那些不熟悉標(biāo)準(zhǔn)化一詞（normalization ）的人而言，標(biāo)準(zhǔn)化可以保證表內(nèi)的字段都是最基礎(chǔ)的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。標(biāo)準(zhǔn)化有好幾種形式，但Third Normal Form（3NF）通常被認(rèn)為在性能、擴(kuò)展性和數(shù)據(jù)完整性方面達(dá)到了最好平衡。簡單來說，3NF 規(guī)定： · 表內(nèi)的每一個(gè)值都只能被表達(dá)一次。 · 表內(nèi)的每一行都應(yīng)該被唯一的標(biāo)識（有唯一鍵）。 · 表內(nèi)不應(yīng)該存儲依賴于其他鍵的非鍵信息。 遵守3NF 標(biāo)準(zhǔn)的數(shù)據(jù)庫具有以下特點(diǎn)：有一組表專門存放通過鍵連接起來的關(guān)聯(lián)數(shù)據(jù)。比方說，某個(gè)存放客戶及其有關(guān)定單的3NF 數(shù)據(jù)庫就可能有兩個(gè)表：Customer 和Order。Order 表不包含定單關(guān)聯(lián)客戶的任何信息，但表內(nèi)會(huì)存放一個(gè)鍵值，該鍵指向Customer 表里包含該客戶信息的那一行。 更高層次的標(biāo)準(zhǔn)化也有，但更標(biāo)準(zhǔn)是否就一定更好呢？答案是不一定。事實(shí)上，對某些項(xiàng)目來說，甚至就連3NF 都可能給數(shù)據(jù)庫引入太高的復(fù)雜性。 為了效率的緣故，對表不進(jìn)行標(biāo)準(zhǔn)化有時(shí)也是必要的，這樣的例子很多。曾經(jīng)有個(gè)開發(fā)財(cái)務(wù)分析軟件的活就是用非標(biāo)準(zhǔn)化表把查詢時(shí)間從平均40 秒降低到了兩秒左右。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標(biāo)準(zhǔn)化當(dāng)作當(dāng)然的設(shè)計(jì)理念。而具體的操作不過是一種派生。所以如果表出了問題重新產(chǎn)生非標(biāo)準(zhǔn)化的表是完全可能的。 7. Microsoft Access 報(bào)表技巧 如果你正在使用Microsoft Access，你可以用對用戶友好的字段名來代替編號的名稱：比如用Customer Name 代替txtCNaM。這樣，當(dāng)你用向?qū)С绦騽?chuàng)建表單和報(bào)表時(shí)，其名字會(huì)讓那些不是程序員的人更容易閱讀。 8. 不活躍或者不采用的指示符 增加一個(gè)字段表示所在記錄是否在業(yè)務(wù)中不再活躍挺有用的。不管是客戶、員工還是其他什么人，這樣做都能有助于再運(yùn)行查詢的時(shí)候過濾活躍或者不活躍狀態(tài)。同時(shí)還消除了新用戶在采用數(shù)據(jù)時(shí)所面臨的一些問題，比如，某些記錄可能不再為他們所用，再刪除的時(shí)候可以起到一定的防范作用。 9. 使用角色實(shí)體定義屬于某類別的列 在需要對屬于特定類別或者具有特定角色的事物做定義時(shí)，可以用角色實(shí)體來創(chuàng)建特定的時(shí)間關(guān)聯(lián)關(guān)系，從而可以實(shí)現(xiàn)自我文檔化。 這里的含義不是讓PERSON 實(shí)體帶有Title 字段，而是說，為什么不用PERSON 實(shí)體和PERSON_TYPE 實(shí)體來描述人員呢？然后，比方說，當(dāng)John Smith, Engineer 提升為John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不過是改變兩個(gè)表PERSON 和PERSON_TYPE 之間關(guān)系的鍵值，同時(shí)增加一個(gè)日期/時(shí)間字段來知道變化是何時(shí)發(fā)生的。這樣，你的PERSON_TYPE 表就包含了所有PERSON 的可能類型，比如Associate、Engineer、Director、CIO 或者CEO 等。 還有個(gè)替代辦法就是改變PERSON 記錄來反映新頭銜的變化，不過這樣一來在時(shí)間上無法跟蹤個(gè)人所處位置的具體時(shí)間。 10. 采用常用實(shí)體命名機(jī)構(gòu)數(shù)據(jù) 組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和PHONE 等等。當(dāng)你把這些常用的一般名字組合起來或者創(chuàng)建特定的相應(yīng)副實(shí)體時(shí)，你就得到了自己用的特殊版本。開始的時(shí)候采用一般術(shù)語的主要原因在于所有的具體用戶都能對抽象事物具體化。 有了這些抽象表示，你就可以在第2 級標(biāo)識中采用自己的特殊名稱，比如，PERSON 可能是Employee、Spouse、Patient、Client、Customer、Vendor 或者Teacher 等。同樣的，ORGANIZATION 也可能是MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最后ADDRESS 可以具體為Site、Location、Home、Work、Client、Vendor、Corporate 和FieldOffice 等。 采用一般抽象術(shù)語來標(biāo)識“事物”的類別可以讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面獲得巨大的靈活性，同時(shí)這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。 11. 用戶來自世界各地 在設(shè)計(jì)用到網(wǎng)絡(luò)或者具有其他國際特性的數(shù)據(jù)庫時(shí)，一定要記住大多數(shù)國家都有不同的字段格式，比如郵政編碼等，有些國家，比如新西蘭就沒有郵政編碼一說。 12. 數(shù)據(jù)重復(fù)需要采用分立的數(shù)據(jù)表 如果你發(fā)現(xiàn)自己在重復(fù)輸入數(shù)據(jù)，請創(chuàng)建新表和新的關(guān)系。 13. 每個(gè)表中都應(yīng)該添加的3 個(gè)有用的字段 · dRecordCreationDate，在VB 下默認(rèn)是Now()，而在SQL Server 下默認(rèn)為GETDATE() · sRecordCreator，在SQL Server 下默認(rèn)為NOT NULL DEFAULT USER · nRecordVersion，記錄的版本標(biāo)記；有助于準(zhǔn)確說明記錄中出現(xiàn)null 數(shù)據(jù)或者丟失數(shù)據(jù)的原因。 14. 對地址和電話采用多個(gè)字段 描述街道地址就短短一行記錄是不夠的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數(shù)據(jù)表，其間具有自身的類型和標(biāo)記類別。 過分標(biāo)準(zhǔn)化可要小心，這樣做可能會(huì)導(dǎo)致性能上出現(xiàn)問題。雖然地址和電話表分離通常可以達(dá)到最佳狀態(tài)，但是如果需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如Customer 等）更為妥當(dāng)些。非標(biāo)準(zhǔn)化和加速訪問之間的妥協(xié)是有一定意義的。 15. 使用多個(gè)名稱字段 我覺得很吃驚，許多人在數(shù)據(jù)庫里就給name 留一個(gè)字段。我覺得只有剛?cè)腴T的開發(fā)人員才會(huì)這么做，但實(shí)際上網(wǎng)上這種做法非常普遍。我建議應(yīng)該把姓氏和名字當(dāng)作兩個(gè)字段來處理，然后在查詢的時(shí)候再把他們組合起來。 要把這種情況變得對用戶更為友好有好些方法。我最常用的是在同一表中創(chuàng)建一個(gè)計(jì)算列，通過它可以自動(dòng)地連接標(biāo)準(zhǔn)化后的字段，這樣數(shù)據(jù)變動(dòng)的時(shí)候它也跟著變。不過，這樣做在采用建模軟件時(shí)得很機(jī)靈才行?？傊捎眠B接字段的方式可以有效的隔離用戶應(yīng)用和開發(fā)人員界面。 16. 提防大小寫混用的對象名和特殊字符 過去最令我惱火的事情之一就是數(shù)據(jù)庫里有大小寫混用的對象名，比如CustomerData。這一問題從Access 到Oracle 數(shù)據(jù)庫都存在。我不喜歡采用這種大小寫混用的對象命名方法，結(jié)果還不得不手工修改名字。想想看，這種數(shù)據(jù)庫/應(yīng)用程序能混到采用更強(qiáng)大數(shù)據(jù)庫的那一天嗎？采用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字符之間留空格。 17. 小心保留詞 要保證你的字段名沒有和保留詞、數(shù)據(jù)庫系統(tǒng)或者常用訪問方法沖突，比如，最近我編寫的一個(gè)ODBC 連接程序里有個(gè)表，其中就用了DESC 作為說明字段名。后果可想而知！DESC 是DESCENDING 縮寫后的保留詞。表里的一個(gè)SELECT *語句倒是能用，但我得到的卻是一大堆毫無用處的信息。 18. 保持字段名和類型的一致性 在命名字段并為其指定數(shù)據(jù)類型的時(shí)候一定要保證一致性。假如字段在某個(gè)表中叫做“agreement_number”，你就別在另一個(gè)表里把名字改成“ref1”。假如數(shù)據(jù)類型在一個(gè)表里是整數(shù)，那在另一個(gè)表里可就別變成字符型了。記住，你干完自己的活了，其他人還要用你的數(shù)據(jù)庫呢。 19. 仔細(xì)選擇數(shù)字類型 在SQL 中使用smallint 和tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是smallint，那么，如果總額超過了$32,767 你就不能進(jìn)行計(jì)算操作了。 20. 刪除標(biāo)記 在表中包含一個(gè)“刪除標(biāo)記”字段，這樣就可以把行標(biāo)記為刪除。在關(guān)系數(shù)據(jù)庫里不要單獨(dú)刪除某一行；最好采用清除數(shù)據(jù)程序而且要仔細(xì)維護(hù)索引整體性。 |
|
|
