SQL Server資料庫學習筆記-設計表時應該考慮的因素

標籤：ar   使用   資料   問題   時間   管理   資料庫   sql   學習   

設計資料庫其實就是設計資料庫中的表。到底要注意些什麼才能夠設計好一個資料庫呢？一個宗旨，8個建議。

一個宗旨“盡量少的表，每個表中盡量少的列，合理的表結構”。

8個建議：

第一個，首先要考慮的是咱們這個資料庫的主要作用是什嗎？至少包含哪些資料？這些資料又分別屬於哪些實體物件？對象之間又存在什麼樣的關係？比如說新聞文章管理系統的資料庫，它要存放的資料至少包括：文章分類、文章標題、發文時間、作者；而既然是管理系統，那麼肯定會有人要添加、刪除或修改文章，那麼就延伸出管理員，有管理員了就存在帳號、密碼；如果還要有對文章的評論功能，那就還得有評論的標題、評論的內容、評論人姓名、評論時間等。這麼多需要存放的資料，如何歸類？歸類後又如何整理相互之間的關係呢？這就需要用到工具。

第二，E-R模型。建立E-R模型的工具很多，甚至紙、筆也算是一種工具。E-R圖的畫法很多，它的主要作用是將所有要存入資料庫的資料歸類、整理成一個個的分類，這個分類被稱為實體，而被歸入這個分類的資料則被稱之為實體的屬性。不同的實體之間存在關聯，比如文章和管理員之間就存在誰發布了文章，文章和評論之間存在某條評論是屬於哪篇文章這樣的關係，在E-R模型上就必須把這些關係體現出來。

第三，每個實體就是一個表，而實體的屬性就是這個表的列，那麼問題就出來了，到底什麼樣的列該用什麼樣的資料類型，比如文章的標題就該用什麼資料類型呢？假如說用NChar(50)，接著來看文章標題用NChar(50)儲存有沒有問題。首先我們說什麼情況下用NChar類型呢？一是在在Unicode字元的時候用N開頭的類型，其次只有在資料長度基本差不多的情況下採用。但是文章的標題每一個都會是固定長度嗎？而且char類型最致命的一個卻顯示，只要用他的資料、只要長度不夠，就自動填滿空格。問題就出來了，如果連續10萬行資料的這一列都只有40個字元，那麼每行增加10個空格，這樣下來10萬*10字元的空間實際上就白白地被佔用了。資料庫的體積越大，處理資料的效率必然受影響。再比如說使用者註冊年齡的問題，肯定首選tinyint，因為目前的人類的年齡不可能超過255歲，而這個類型只佔1位元組的空間，如果習慣性地用int類型，咋一看也沒有問題，只是白白浪費了3個位元組的空間，因為int是4位元組的長度。總結一下，不浪費空間，也不過分節約空間，適量而行。

第四，允許為空白和預設值。這是什麼意思呢？首先要明確什麼是空值，什麼是預設值。這裡的空值既不是0也不是Null 字元，而表示未知，用null表示。這就有問題了，首先，如果處在變長類型列中的null值本身雖然不佔空間，但是它所在的列卻實實在在地佔用空間的。再則null比較特殊，資料庫要對null欄位進行額外的操作，所以如果表中有較多的null欄位時會影響資料庫的效能；還有一點是我們現在想不到但將來一定遇到的，null欄位會給編程帶來一些不大不小的麻煩，比如製造一些bug。所以，一句話，盡量少用允許列為空白，如果一定要允許也盡量將之靠後。遇到使用者可能不願意填或亂填的情況，就要用到預設值。比如說使用者的註冊時間。

第五，主鍵的問題。每張表都需要一個主鍵，用來標識唯一的一條資料。

第六，約束和規則。用於確保資料的完整有效性，一旦定義了約束的規則，那麼中有滿足這些條件的資料才可以插入資料庫。比如要求註冊會員的性別要麼是男，要麼是女，絕對不允許第三種情況，再比如年齡只能是18~80歲，其他註冊不了。

第七，外鍵關係。設定外鍵可以節省空間的，方便編程和程式的擴充。

第八，考慮是否使用索引。索引也是一種資料庫物件，於是在哪些列上使用索引，對哪些列不適用索引；是使用聚簇索引還是非聚簇索引；是否使用全文索引等等。很多問題需要認真地思考。

SQL Server資料庫學習筆記-設計表時應該考慮的因素