數(shù)據(jù)庫設計經(jīng)驗談(編輯修改稿)
2025-08-31 16:50 本頁面
【文章內(nèi)容簡介】 ssociate、Engineer、Director、CIO或者CEO等。還有個替代辦法就是改變PERSON記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。采用常用實體命名機構(gòu)數(shù)據(jù)組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS和PHONE等等。當你把這些常用的一般名字組合起來或者創(chuàng)建特定的相應副實體時，你就得到了自己用的特殊版本。開始的時候采用一般術語的主要原因在于所有的具體用戶都能對抽象事物具體化。有了這些抽象表示，你就可以在第2級標識中采用自己的特殊名稱，比如，PERSON可能是Employee、Spouse、Patient、Client、Customer、Vendor或者Teacher等。同樣的，ORGANIZATION也可能是MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government等。最后ADDRESS可以具體為Site、Location、Home、Work、Client、Vendor、Corporate和FieldOffice等。采用一般抽象術語來標識“事物”的類別可以讓你在關聯(lián)數(shù)據(jù)以滿足業(yè)務要求方面獲得巨大的靈活性，同時這樣做還可以顯著降低數(shù)據(jù)存儲所需的冗余量。用戶來自世界各地在設計用到網(wǎng)絡或者具有其他國際特性的數(shù)據(jù)庫時，一定要記住大多數(shù)國家都有不同的字段格式，比如郵政編碼等，有些國家，比如新西蘭就沒有郵政編碼一說。數(shù)據(jù)重復需要采用分立的數(shù)據(jù)表如果你發(fā)現(xiàn)自己在重復輸入數(shù)據(jù)，請創(chuàng)建新表和新的關系。每個表中都應該添加的3個有用的字段*dRecordCreationDate，在VB下默認是Now()，而在SQLServer下默認為GETDATE()*sRecordCreator，在SQLServer下默認為NOTNULLDEFAULTUSER*nRecordVersion，記錄的版本標記；有助于準確說明記錄中出現(xiàn)null數(shù)據(jù)或者丟失數(shù)據(jù)的原因?qū)Φ刂泛碗娫挷捎枚鄠€字段描述街道地址就短短一行記錄是不夠的。Address_LineAddress_Line2和Address_Line3可以提供更大的靈活性。還有，電話號碼和郵件地址最好擁有自己的數(shù)據(jù)表，其間具有自身的類型和標記類別。過分標準化可要小心，這樣做可能會導致性能上出現(xiàn)問題。雖然地址和電話表分離通?？梢赃_到最佳狀態(tài)，但是如果需要經(jīng)常訪問這類信息，或許在其父表中存放“首選”信息（比如Customer等）更為妥當些。非標準化和加速訪問之間的妥協(xié)是有一定意義的。使用多個名稱字段我覺得很吃驚，許多人在數(shù)據(jù)庫里就給name留一個字段。我覺得只有剛?cè)腴T的開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。我建議應該把姓氏和名字當作兩個字段來處理，然后在查詢的時候再把他們組合起來。我最常用的是在同一表中創(chuàng)建一個計算列[字段]，通過它可以自動地連接標準化后的字段，這樣數(shù)據(jù)變動的時候它也跟著變。不過，這樣做在采用建模軟件時得很機靈才行?？傊捎眠B接字段的方式可以有效的隔離用戶應用和開發(fā)人員界面。提防大小寫混用的對象名和特殊字符過去最令我惱火的事情之一就是數(shù)據(jù)庫里有大小寫混用的對象名，比如CustomerData。這一問題從Access到Oracle數(shù)據(jù)庫都存在。我不喜歡采用這種大小寫混用的對象命名方法，結(jié)果還不得不手工修改名字。想想看，這種數(shù)據(jù)庫/應用程序能混到采用更強大數(shù)據(jù)庫的那一天嗎？采用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字符之間留空格。小心保留詞要保證你的字段名沒有和保留詞、數(shù)據(jù)庫系統(tǒng)或者常用訪問方法沖突，比如，最近我編寫的一個ODBC連接程序里有個表，其中就用了DESC作為說明字段名。后果可想而知！DESC是DESCENDING縮寫后的保留詞。表里的一個SELECT*語句倒是能用，但我得到的卻是一大堆毫無用處的信息。保持字段名和類型的一致性在命名字段并為其指定數(shù)據(jù)類型的時候一定要保證一致性。假如字段在某個表中叫做“agreement_number”，你就別在另一個表里把名字改成“ref1”。假如數(shù)據(jù)類型在一個表里是整數(shù)，那在另一個表里可就別變成字符型了。記住，你干完自己的活了，其他人還要用你的數(shù)據(jù)庫呢。仔細選擇數(shù)字類型在SQL中使用smallint和tinyint類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是smallint，那么，如果總額超過了$32,767你就不能進行計算操作了。刪除標記在表中包含一個“刪除標記”字段，這樣就可以把行標記為刪除。在關系數(shù)據(jù)庫里不要單獨刪除某一行；最好采用清除數(shù)據(jù)程序而且要仔細維護索引整體性。避免使用觸發(fā)器觸發(fā)器的功能通?？梢杂闷渌绞綄崿F(xiàn)。在調(diào)試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，你最好集中對它文檔化。包含版本機制建議你在數(shù)據(jù)庫中引入版本控制機制來確定使用中的數(shù)據(jù)庫的版本。無論如何你都要實現(xiàn)這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數(shù)據(jù)庫結(jié)構(gòu)。雖然你可以通過檢查新字段或者索引來確定數(shù)據(jù)庫結(jié)構(gòu)的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎？給文本字段留足余量ID類型的文本字段，比如客戶ID或定單號等等都應該設置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設你的客戶ID為10位數(shù)長。那你應該把數(shù)據(jù)庫表字段的長度設為12或者13個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長3個字符在有1百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù)3MB的空間。但這額外占據(jù)的空間卻無需將來重構(gòu)整個數(shù)據(jù)庫就可以實現(xiàn)數(shù)據(jù)庫規(guī)模的增長了。身份證的號碼從15位變成18位就是最好和最慘痛的例子。列[字段]命名技巧我們發(fā)現(xiàn)，假如你給每個表的列[字段]名都采用統(tǒng)一的前綴，那么在編寫SQL表達式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，后者把公共列[字段]
范文總結(jié)相關推薦
鄂ICP備17016276號-1