SQL資料庫表設計

通常情況下，可以從兩個方面來判斷資料庫設計的是否規範：

1）看是否擁有大量的窄表

2）看寬表的數量是否足夠的少

所謂的寬表就是字段比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀正規化設計，但是有利於取數。

當然，資料庫表設計最好遵循以下五個要求：

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

2）表中不該有重複的值或者列。如進銷存系統中，需要對客戶的聯絡人進行管理。有時候企業可能只知道客戶乙個採購員的名字，但是在必要的情況下，企業需要對客戶的採購代表、倉管員、財務員共同進行管理。因為在訂單上，可能需要填入採購員的名字，可是在出貨單上，則需要填入倉管員的名字等等。為了解決這個問題，有很多種方式，但是若設計不合理的話，則會導致很多重複的列或者值，如果我們這麼設計，把客戶的資訊、聯絡人都放入一張表中。為了解決多個聯絡人的問題，可以設定第一聯絡人及**、第二聯絡人及**、第三聯絡人及**等等。則可能還需要更多字段。所以我們在設計資料庫的時候盡量避免重複的值或者列的產生。建議把客戶聯絡人另外設定一張表。然後通過客戶id把**商資訊表和客戶聯絡人資訊表連線起來。也就是說盡量將重複的值放置到一張獨立的表中進行管理。然後通過檢視或者其他手段把這些獨立的表聯絡起來。

3）表中記錄應該有乙個唯一的識別符號。在資料庫設計的時候，應該用乙個id號來唯一的標識記錄，而不要通過名字、編號等字段來對記錄進行區分，每個表應該有乙個id列，任何兩個記錄都不可以共享同乙個id值，另外這個id值最好有資料庫進行統一自動管理，而不要把這個任務給前台應用程式。否則的話，很容易產生id值不統一的情況。另外，在設計資料庫的時候，最好加入行號。例如在銷售訂單管理中，id號是使用者不能夠維護的，但是，行號使用者就可以維護。在銷售訂單的行號中，使用者可以通過調整行號的大小來對訂單進行排序。通常情況下，id列是以1為單位遞進的。但是行號就要以10為單位累進，如此，在正常情況下，行號是以10,20,30依次擴充套件下去。若此時使用者需要把行號為30 的調整到第一行顯示，此時使用者在不改id列的情況下，可以更改行號來實現。如把行號改為1，就可以在排序時按行號來排序。

4）資料庫物件要有統一的字首名。乙個比較複雜的應用系統，其對應的資料庫表可能上千個的，若要讓資料庫管理員看到表名就知道這個資料庫表所起的作用，恐怕會比較困難，而且在資料庫物件引用的時候，資料庫管理員也會為不能快速找到所需的資料庫物件而頭疼。其次表、檢視、函式等最好也有統一的字首。如表可以用t，檢視可以用v，函式用f。

5）盡量只儲存單一實體型別的資料。這裡說的實體型別跟資料型別不是一回事，要注意區分，這裡的實體型別是所需要描述物件的本身。舉個例子，例如有乙個圖書管理系統，有圖書基本資訊、作者資訊兩個實體物件，若要把這兩個實體物件資訊放在同一張表中也是可以的，可以把錶設計成圖書名字、圖書作者等，可是如此的話，會給後續的維護帶來不少的麻煩。當後續有圖書出版時，則需要為每次的圖書增加作者資訊，這無疑會增加額外的儲存空間，也會增加記錄的長度，而且若作者的情況有所改變，如位址變了，則還需要去更改每一本書的記錄。同時，若這個作者的圖書從資料庫刪除了，這個作者的資訊也沒有了，很明顯，這不符合資料庫設計規範的需求。遇到這種情況，建議把上面的這張表拆分成3個表，分別為圖書基本資訊表、作者基本資訊表、圖書與作者對應表等。

SQL資料庫表設計

SQL資料庫》資料庫設計

資料庫表設計

資料庫表設計

相關推薦