SQL資料庫設計(二) -- 物理設計
阿新 • • 發佈：2019-02-02
今天主要介紹資料庫設計的物理設計,上一篇文章已經講了,資料庫設計的需求分析和邏輯設計,如果你沒有看到,請點選下面的連線:
SQL資料庫設計（一）—需求分析與邏輯設計
物理設計
根據資料庫自身的特點把邏輯設計轉換成物理設計。
1.選擇合適的資料庫管理系統
常見的資料庫系統
以MySQL為例，介紹儲存引擎
| 儲存引擎 | 事務 | 鎖粒度 | 主要應用 | 忌用 |
|---|---|---|---|---|
| MyISAM(mysql5.5以下預設) | 不支援 | 支援併發插入的表級鎖 | Select多 Insert少 | 讀寫操作頻繁 |
| MRG_MyISAM | 不支援 | 支援併發插入的表級鎖 | 分段歸檔，資料倉庫 | 全域性查詢過多的場景 |
| Innodb(5.5以上預設) | 支援 | 支援MVCC的行級鎖 | 事務處理 | 無 |
| Archive（日誌系統） | 不支援 | 行級鎖 | 日誌記錄，只支援insert，select | 需要隨機讀取，更新，刪除 |
| Ndb cluster（MySQL叢集使用） | 支援 | 行級鎖 | 高可用性 | 大部分應用 |
2.定義資料庫，表及欄位的命名規範
所有物件的命名應該遵循下面原則
1.可讀性原則(使用大寫和小寫結合的方式來格式化庫物件的名字已獲得良好的可讀性.)
2.表意性原則
(物件的名字應該能描述他所標示的物件.)3.長名原則(儘量不要使用縮寫)
3.根據DBMS系統選擇合適的欄位型別
欄位型別的選擇原則:
列的資料型別一方面影響資料儲存空間的開銷,另一方面也會影響資料查詢的效能.
當一個列可以選擇多種資料型別時,優先考慮數字型別,其次是日期或二進位制型別,最後是字元型別.
對於相同級別的資料型別,應該優先選擇佔用空間小的資料型別.**
mysql的欄位型別
char 與varchar的選擇原則:
如果列中要儲存的資料差不多長度，則選擇char，否則考慮varchar 如果列中最大資料長度小於50Byte，則一般考慮使用char 一般不宜定義大於50byte的char型別列
decimal和float選擇原則：
1.decimal用於儲存精確資料，而float只能用於儲存非精確資料
2.由於float的儲存開銷比decimal小，所以優先選擇float資料型別
如何儲存時間型別：
1.使用int儲存時間欄位 優點：欄位長度比datetime小；缺點：使用不方便，要進行函式轉換（並且有時間上限）
2.根據時間粒度，選擇不同的日期型別
不同資料型別的比較原則
- 在對資料進行比較(查詢,join,排序)操作時,同樣的資料,字元處理往往比數字處理慢.
- 在資料庫中,資料處理以頁為單位,列的長度越小,利於效能的提升.
如何選擇主鍵：
1.區分業務主鍵和資料庫主鍵
業務主鍵用於標示業務資料,進行表與表之間的關聯;
資料庫主鍵用於優化資料儲存.(Innodb會生成6個位元組得到隱含主鍵)
2.根據資料庫型別,考慮主鍵是否要順序增長.
有些資料庫是按照主鍵的順序邏輯儲存的.
3.主鍵的欄位型別所佔空間要儘可能的小
對於使用聚集索引方式儲存的表,每個索引後都會附加主鍵資訊.
避免使用外來鍵約束
1. 降低資料匯入的效率.
2.增加維護成本.
3.雖然不建議使用外來鍵約束,但相關聯列上一定要建上索引.
避免使用觸發器
1.降低資料匯入的效率.
2.出現不可預料的資料異常
3.使業務邏輯變得複雜
4.反正規化化設計。
為了效能和讀取效率的考慮,適當的對第三正規化的要求進行違反,而允許存在少量的資料冗餘.
當資料庫以讀為主時,可以適度進行反正規化化,提高讀取效率.
使用空間換取時間.
反正規化化設計舉例:
這個數資料庫完全符合第三正規化,但是查詢時需要聯結大量的表,導致讀取效率偏低.
為了提高讀取效率,我們適當的增加一下冗餘欄位,可以有效的減少聯結表的個數,提高讀取效率.
使用反正規化化得好處 :
- 減少表的關聯數量
- 增加資料的讀取效率
- 反正規化化一定要適度
物理設計就介紹到這裡了,明天講下索引優化,結束資料庫設計.