關係型: Mysql, Oracle
非關係型: Mongodb, Redis
數據庫設計
減少數據冗餘，避免數據維護異常，節約儲存空間，高效的訪問
設計步驟
需求分析：數據是什麼，有哪些屬性，數據和屬性的特點（存儲特點），數據的生命週期
邏輯設計：使用ER圖對數據庫進行邏輯設計
物理設計：把邏輯設計轉成物理設計
維護優化：新的需求進行建表，索引優化，大表拆分
需求分析
1. 實體及實體之間的關係（11 1n nn）
2. 實體所包含的屬性
3. 那些屬性或屬性的組合可以唯一標識一個實體
實例
以一個小型電子商務網站爲例。用戶模塊，商品模塊，訂單模塊，購物車模塊，供應商模塊
用戶模塊：記錄註冊用戶信息。唯一標示-用戶名，身份證，電話。儲存特點，增長，永久儲存你。
商品模塊：…….，可以對下線商品歸檔存儲（不能刪除因爲涉及訂單等，可以遷移）。
訂單模塊：………，永久存儲（分表，分庫存儲）
購物車模塊：……….，不用永久存儲（設置歸檔，清理規則）
供應商模塊：…….，永久存儲
關係：
邏輯設計
1. 將需求轉化爲數據庫的邏輯模型
2. 通過ER圖的型式對邏輯模型進行展示
3. 同所選用的具體的DBMS系統無關
三大範式
第一範式：數據庫表中的所有字段都是單一屬性，不可再分的。這個單一屬性是由基本數據類型所構成的。即第一範式要求數據庫的表都是二維表。
第二範式：數據庫的表中不存在非關鍵字段對任意候選關鍵字段的部分函數依賴。部分函數依賴是指存在着組合關鍵字中的某一關鍵字決定非關鍵字的情況。即所有但關鍵字段的表都符合第二範式。
第三範式：二範式在三範式之上，如果數據表中不存在非關鍵字段對任意候選關鍵字段的傳遞函數依賴規則則符合第三範式。
BC範式：如果複合關鍵字，則複合關鍵字之間也不能存在傳遞函數依賴關係。（即把第三範式中的非關鍵字段升級爲關鍵字及其分關鍵字段）
物理設計—設計標的結構
1. 選擇合適的數據庫管理系統
2. 定義數據庫，表及字段的命名規範
3. 根據所選的DBMS系統選擇合適的字段類型 varchar/char如何選擇等
4. 反範式化設計 即增加冗餘，用空間換取效率的提升
Mysql常用引擎： MylSAM 不支持事務。支持併發插入的表級鎖。主要select，insert 。不易頻繁讀寫。
MRG-MYISAM不支持事務。支持併發插入的表級鎖。主要分段歸檔，數據倉庫。不易全局查找過多的場景。
Innodb支持事務。支持MVCC的行級鎖。主要事務處理。
Archive 不支持事務。行級鎖。主要日誌記錄，只支持insert，select。不易需要隨機讀取，更新，刪除。存儲容量小。
Ndb cluster 支持事務。行級鎖。主要高可用性。推薦使用。（mysql集羣）
表及字段的命名規則
1. 可讀性原則 （駝峯命名，但注意表名的大小寫敏感）
2. 表意性原則 表明對象、數據內容、存儲過程
3. 長名原則 儘可能少用或不用縮寫
字段類型的選擇原則
數據類型印象存儲空間開銷和查詢性能。可以選擇多數據類型時，優先數字，其次日期或二進制，最後字符串。同級別數據類型，優先佔空間小的。
1. 同樣的數據進行比較時（查詢條件，join及排序）時，字符處理比數字慢。
2. 在數據庫中，數據處理以頁爲單位，列的長度越小，利於性能提升。
Char和varchar如何選擇
1. 數據長度差不多的選擇char，數據長度不一致的時候varchar。
2. 列的最大數據長度小於50Byte，一般用char，但是如果這個列很少用，基於節省空間和減少I/O的考慮，可以選擇varchar。
3. 一般不宜定義大於50Byte的char類型。
Decimal和float
1. decimal用於存儲精確數據，float只能用於存儲非精確數據。
2. float存儲空間開銷一般小於decimal（7位小數要4個字節，15位小數要8個字節）
時間類型
1. int 字段長度比datetime小，但是用不方便需要函數轉換，只能存儲到2038-1-19 11:14:07。在不經常查詢時間的時候用int。
2. 存儲的時間粒度 年月日小時分秒周
如何選擇主鍵
1. 業務主鍵用於表示業務數據，進行表與標的之間的關聯。數據庫主鍵爲了優化數據存儲（Innodb不手動設主鍵會自動生成6字節隱含主鍵）。
2. 根據數據庫的類型，考慮主鍵是否要順序增長。
3. 主鍵的字段類型所佔空間要儘可能的小，對於使用聚集索引方式存儲的表，每個索引後都會附件主鍵信息。
4.
避免使用外鍵約束
1. 雖然保持數據完整性，但是降低數據導入的效率。（高併發的時候每次查詢都會檢測是否符合外檢）
2. 降低維護成本。
3. 雖然不建議使用外鍵，但是相關聯的列上一樣要建立索引。
4.
避免使用觸發器
1. 降低數據導入效率。
2. 可能會出現意想不到的數據異常。
3. 是業務邏輯變的複雜。
4.
關於預留字段
1. 無法正確指導預留字段類型和存儲內容。
2. 後期維護預留字段所要的成本同增加一個字段所需的成本是相同的。
3. 嚴禁使用預留字段。
反範式化
違反第三範式，通過空間來換取時間。
1. 減少表的關聯數量。
2. 增加數據的讀取效率。
3. 反範式化一定要適度。
維護優化
1. 維護數據字典 要記住字典中每個數字代表什麼含義 可以使用第三方工具也可以使用備註字段來維護 comment’ ’ 。
2. 維護索引 where groupby orderby的從句 可選擇性高的列要放到索引的前面 不要包括太長的數據類型 過多的索引會降低褻瀆效率 定期維護索引碎片 sql語句中不要使用強制索引關鍵字。
3. 維維護表結構 列的變更 控制表的寬度和大小（拆分）。
4. 在適當的時候對錶進行水平拆分（表結構相同，Hash key）或垂直拆分（中間切分表，表結構不同）。
適合的操作 批量操作（不適合逐條操作）
禁止使用select *查詢（I/O浪費，表結構改了數據錯誤）
控制使用用戶自定義函數（影響索引 使用函數則列中索引失效）
不要使用數據庫中的全文索引（維護高，不適合中文）