天天看點

Oracle資料庫的幾種設計規範

一般情況下,可以從兩個方面來判斷資料庫是否設計的比較規範,1是看是否擁有大量的窄表,2是寬表的數量是否足夠的少,如果符合這兩個條件,則可以說明這個資料庫的設計水準還是比較高的,當然這是兩個表面上的名額,為了達到資料庫設計規範的要求,一般來說,需要符合以下幾個要求。

  1. 表中要避免可為空的列。

    雖然表中允許有空列,但是,空字段是一種比較特殊的資料類型,資料庫在處理的時候 需要進行特殊的處理,這樣的話,就會增加資料庫處理記錄的複雜性,當表中要比較多的空字段時,在同等條件下,資料庫處理的性能會降低許多,是以,雖然在資料庫表的設計的時候,允許表中具有空字段,但是,我們應該盡量避免,若的确需要的話,可以通過一些折中的方式,來處理這些空字段,讓他對資料庫性的影響降到最低。

通過設定預設值的形式,來避免空字段的産生,如一個商城VIP系統,有的時候身份證号字段可以為空,因為不是每個人都能記得住身份證号的,辦理業務時身份證沒帶身上不能及時提供,是以身份證号碼字段可以為空,滿足這些特殊需求,但是,在資料庫設計的時候,就要做一些處理了,如果使用者沒有輸入的時候,把這個字段的val預設值改為0/1,這樣能避免空字段的産生。若是一張表中,允許為空的列比較多,接近全部列數的三分之一,而且,這些列在大部分情況下,都是可有可無的,如果資料庫管理者遇到這樣的狀況,建議另外建立一張副表,以儲存這些列,然後通過關鍵字把主表和副表關聯起來,把資料存儲在兩個獨立的表中是的主表的設計更為簡單,同時也能夠滿足存儲空值的資訊需要。

2.表不應該要有重複的Key或val

如果現在有一個進銷存系統,這個系統中有一張成品基本資訊表。這個産品開發有時間可以是一個人完成。

如進銷存管理中,還需要對客戶的聯系人進行管理,有時候,企業可能隻知道客戶一個采購員的姓名,但是必要情況下,企業需要對客戶的采購人員,倉庫人員,财務人員共同進行管理,因為在訂單上,可能需要填入采購代表的名字,在出貨單上,則需要填入倉庫管理人員的名字等等。

為解決這個問題,有多個實作方式,但是,如果設計不會理的話,就會導緻重複的val和key,如我們也可以這麼設計。吧客戶資訊,聯系人都放入同一張表中,為了解決多個聯系人問題,可以設定第一個聯系人 第一聯系人電話 ,第二聯系人 第二聯系人電話等等,如果更多就會有更多字段加入。

可是如果這麼設計會有一系列問題,如客戶的采購員流動性比較大,一年有七八個采購員,這樣的話在用到這樣的設計就顯然不合理了。是以,在資料庫設計的時候要盡量避免這種重複的key或者val的産生,如果用到這種情況,就需要改變一下政策,如:吧客戶聯系人另外設定一張表,然後通過客戶ID把供應商資訊表跟客戶聯系人資訊連接配接起來,就是說盡量把重複的key放至到一張獨立的表中進行管理,然後通過視圖或者其他手段把這些獨立的表關聯起來

3.表中記錄應該有一個辨別符

在資料庫表設計的時候,資料庫管理者就應有個好習慣,用一個ID号碼 辨別進行記錄,而不是通過名字 編号等字段對記錄進行區分,每個表都應該有一個id任何兩個記錄都不能共用一個id值 另外 這個id值最好有資料庫來進行自動管理,而不要吧這個任務給前台應用程式,否則 很容易産生id值不統一的情況

4.資料庫對象要有統一的字首名

一個比較複雜的應用系統,其對應的資料表往往數以千計,鑰匙讓資料庫管理者看到對象名就了解這個資料庫對象所起的作用 這樣比較困難,而且在資料庫對象引用的時候,資料庫管理者也會為不能迅速找到資料對象對發愁。為此在開發資料庫之前,最好花時間去制定一個資料庫的對象的字首命名規範,

如在設計資料庫時和前台應用程式協商,确定合理的命名規範,如和物料管理子產品相關的表可以用M為字首,而訂單管理相關的就用C作為字首,具體采用什麼字首就根據使用者的愛好,但是注意 這個命名規範應該在資料庫管理者和前台應用程式開發者之間達成共識,并且嚴格暗戰這個命名規範來定義對象名。

其次 表 視圖 函數等較好也要有統一的字首,如視圖可以用V為字首 函數用F為字首 這樣資料庫管理者無論在日常管理還是對象引用都能在最短的時間找到自己需要的對象。

5.盡量隻存儲單一實體類型資料。

這裡實體類型和資料類型不是一回事,要注意區分,這裡講的實體類型是指所需要描述對象的本身 舉個例子 如現在有一個圖書館系統,有圖書基本資訊,作者資訊兩個實體對象,若使用者要吧這兩個實體對象資訊放在同一張表中也可以,如果把表設計成圖書的名字,作者等等如果這樣設計的話,回給後續的維護帶來麻煩

如果後續有書出版時,就需要為每次出版的圖書增加作者資訊,這無疑會增加額外的存儲空間,也會增加記錄的長度,而且作者的情況有變,如住址修改,這樣還會修改每本書的記錄,同屬若這個作者的數從庫中全部删除後,跟着這個作者的資訊也就沒了很明顯這不符合資料庫設計規範要求。

遇到這種情況 建議把上面的這張表分為三個獨立的表,分别為圖書基本表 ,作者表 圖書合作者對應表等等 這樣設計 在遇到問題也能迎刃而解。