廢話就不多說了，開始。。。
???? 通常情況下，可以從兩個方面來判斷數據庫是否計劃的比擬標準。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個數據庫的標準化水平還是比擬高的。當然這是兩個泛泛而談的指標。為了達到數據庫計劃標準化的要求，一般來說，需要符合以下五個要求。?
????
????
???? 要求一：表中應該防止可為空的列。
???? ?
????
????
???? 雖然表中允許空列，但是，空字段是一種比擬特殊的數據類型。數據庫在處理的時候，需要停止特殊的處理。如此的話，就會增長數據庫處理記錄的復雜性。當表中有比擬多的空字段時，在同等條件下，數據庫處理的性能會下降許多。?
????
????
???? 所以，雖然在數據庫表計劃的時候，允許表中具有空字段，但是，我們應該盡量防止。若確切需要的話，我們可以通過一些折中的方式，來處理這些空字段，讓其對數據庫性能的影響下降到最少。?
????
????
???? 一是通過設置默認值的情勢，來防止空字段的產生。如在一個人事管理系統中，有時候身份證號碼字段可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼字段往往不能及時供給。為此，身份證號碼字段可以允許為空，以滿意這些特殊情況的需要。但是，在數據庫計劃的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個字段的默認值設置為0或者為N/A。以防止空字段的產生。?
????
????
???? 二是若一張表中，允許為空的列比擬多，接近表全體列數的三分之一。而且，這些列在大部分情況下，都是無關緊要的。若數據庫管理員碰到這種情況，筆者提議另外建立一張副表，以保存這些列。然后通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的計劃更為簡略，同時也能夠滿意存儲空值信息的需要。?
????
????
????
要求二：表不應該有重復的值或者列。?
????
???? 如現在有一個進銷存管理系統，這個系統中有一張產品基本信息表中。這個產品開發有時候可所以一個人實現，而有時候又需要多個人協作才能夠實現。所以，在產品基本信息表產品開發者這個字段中，有時候可能需要填入多個開發者的名字。?
????
????
???? 如進銷存管理中，還需要對客戶的聯系人停止管理。有時候，企業可能只知道客戶一個采購員的姓名。但是在須要的情況下，企業需要對客戶的采購代表、倉庫人員、財務人員共同停止管理。因為在訂單上，可能需要填入采購代表的名字;可是在出貨單上，則需要填入倉庫管理人員的名字等等。?
????
????
???? 為懂得決這個問題，有多種實現方式。但是，若計劃不合理的話在，則會致使重復的值或者列。如我們也可以這么計劃，把客戶信息、聯系人都放入統一張表中。為懂得決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要參加更多的字段。?
????
????
???? 可是這么計劃的話，會產生一系列的問題。如客戶的采購員流動性比擬大，在一年內換了六個采購員。此時，在系統中該如何管理呢?難道就建立六個聯系人字段?這不但會致使空字段的增長，還需要頻繁的變動數據庫表結構。明顯，這么做是不合理的。也有人說，可以直接修改采購員的名字呀。可是這么處理的話，會把原先采購訂單上采購員的名字也改變了。因為采購單上客戶采購員信息在數據庫中存儲的不是采購員的名字，而只是采購員對應的一個編號。在編號不改而名字改變了的情況下，采購訂單上表現的就是變動后的名字。這不利于時候的追蹤。?
????
????
???? 所以，在數據庫計劃的時候要盡量防止這種重復的值或者列的產生。筆者提議，若數據庫管理員碰到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然后通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中停止管理。然后通過視圖或者其他手腕把這些獨立的表聯系起來。?
????
????
????
要求三：表中記錄應該有一個獨一的標識符。
????
????
???? 在數據庫表計劃的時候，數據庫管理員應該養成一個好習慣，用一個ID號來獨一的標識行記錄，而不要通過名字、編號等字段來對記錄停止區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享統一個ID值。另外，這個ID值最好有數據庫來停止自動管理，而不要把這個任務給前臺應用程序。否則的話，很輕易產生ID值不統一的情況。?
????
????
???? 另外，在數據庫計劃的時候，最好還能夠參加行號。如在銷售訂單管理中，ID號是用戶不能夠維護的。但是，行號用戶就能夠維護。如在銷售訂單的行中，用戶可以通過調整行號的巨細來對訂單行停止排序。通常情況下，ID列是以1為單位遞進的。但是，行號就要以10為單位累進。如此，正常情況下，行號就以10、20、30順次擴展下去。若此時用戶需要把行號為30的記錄調到第一行表現。此時，用戶在不能夠變動ID列的情況下，可以變動行號來實現。如可以把行號改成1，在排序時就能夠按行號來停止排序。如此的話，本來行號為30的記錄現在行號變為了1，就能夠在第一行中表現。這是在現實應用程序計劃中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在現實應用程序計劃中，才會把握到這個技巧。?
????
????
????
要求四：數據庫對象要有統一的前綴名。?
????
???? 一個比擬復雜的應用系統，其對應的數據庫表往往以千計。若讓數據庫管理員看到對象名就懂得這個數據庫對象所起的作用，恐怕會比擬困難。而且在數據庫對象引用的時候，數據庫管理員也會為不能迅速找到所需要的數據庫對象而頭疼。?
????
????
???? 為此，筆者建立，在開發數據庫之前，最好能夠花必定的時間，去制訂一個數據庫對象的前綴命名標準。如筆者在數據庫計劃時，喜好跟前臺應用程序協商，確定合理的命名標準。筆者最經常使用的是根據前臺應用程序的模塊來定義后臺數據庫對象前綴名。如跟物料管理模塊相干的表可以用M為前綴;而以訂單管理相干的，則可以利用C作為前綴。具體采取什么前綴可以以用戶的喜好而定義。但是，需要注意的是，這個命名標準應該在數據庫管理員與前臺應用程序開發者之間告竣共識，并且嚴厲按照這個命名標準來定義對象名。?
????
????
???? 其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此數據庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。?
????
????
???? 要求五：盡量只存儲單一實體類型的數據。
???? ?
????
????
???? 這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就能夠明確其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在統一張表中也是可以的。如可以把表計劃成圖書名字、圖書作者等等。可是如此計劃的話，會給后續的維護帶來不少的費事。?
????
????
???? 如當后續有圖書出版時，則需要為每次出版的圖書增長作者信息，這無疑會增長額定的存儲空間，也會增長記錄的長度。而且若作者的情況有所改變，如住址改變了以后，則還需要去變動每本書的記錄。同時，若這個作者的圖書從數據庫中全體刪除之后，這個作者的信息也就蕩然無存了。很明顯，這不符合數據庫計劃標準化的需求。?
????
????
???? 碰到這種情況時，筆者提議可以把下面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此計劃以后，以上碰到的全部問題就都引刃而解了。?
????
????
???? 以上五條是在數據庫計劃時達到標準化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，數據庫標準往往沒有技巧方面的嚴厲制約，主要依托數據庫管理員日常工作經驗的累積。
文章結束給大家分享下程序員的一些笑話語錄： 關于編程語言
如果 C++是一把錘子的話，那么編程就會變成大手指頭。
如果你找了一百萬只猴子來敲打一百萬個鍵盤，那么會有一只猴子會敲出一 段 Java 程序，而其余的只會敲出 Perl 程序。
一陣急促的敲門聲，“誰啊！”，過了 5 分鐘，門外傳來“Java”。
如果說 Java 很不錯是因為它可以運行在所有的操作系統上，那么就可以說 肛交很不錯，因為其可以使用于所有的性別上。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
