一對一關係：
一對多模型：
商城中的 商品表shop_product 和 商品物品表 shop_product_item 是 一對多關係 。 關聯字段是shop_product_item的product_id字段
多對多模型：
合能項目中 角色表manager_role 和 菜單表manager_menu 是多對多關係。中間表爲manager_role_menu
三大範式：
1NF：
數據庫表的每一列都是不可分割的基本數據項；
2列的屬性相近或者相似，儘量合併成一樣的列
2NF:
首先滿足1NF，要求表的每條記錄可以唯一區分（主關鍵字），要求實體(記錄)的非主屬性完全依賴於主關鍵詞。
3NF：
必須先滿足2NF ； 要求表中的每一列只與主鍵直接相關而不是間接相關。
3大範式總結：
- 2列的屬性相近或者相似，儘量合併成一樣的列
- 第二範式是說一張表中包含了所種不同的實體屬性，那麼要必須分成多張表，
- 第三範式是要求已經分成了多張表，那麼一張表中只能有另一張表中的id（主鍵），而不能有其他的任何信息（其他的信息一律用主鍵在另一表查詢）。
數據庫命名：
- 字段和表名稱 應該是 a_b , 用下劃線隔開
navicat查看mysql表的關係：
數據庫設計:
概念：
- 根據業務系統需要，結合選用的DBMS，爲業務系統構造出最優的數據存儲模型，建立好數據庫中表結構及表與表之間的管理關係
爲什麼要進行數據庫設計？？
物理設計：
目的：建立表結構
1、選擇數據庫系統：應用特點、成本
2、定義庫、表、字段的命名規範（數據庫系統對此有限制）
3、根據系統選擇合適的字段類型
4、反範式化設計：增加冗餘，提高效率備註：反範式，不滿足範式的模型，就是反範式模型。反範式跟範式所要求的正好相反，在反範式的設計模式，我們可以允許適當的數據的冗餘，用這個冗餘去取操作數據時間的縮短。本質上就是用空間來換取時間，把數據冗餘在多個表中，當查詢時可以減少或者是避免表之間的關聯。（如果關聯查詢效率很低，可以考慮使用反範式設計）
選擇哪種數據庫？？
- 成本 方面
- 事務成本 （大的事務操作）
備註：事務的大小通常是指一個事務中所處理的數據的多少和所包括的SQL語句的數量，比如說，我們在一個事務中既包括了UPDATE，INSERT，DELETE語句同時以有大量的SELECT語句那邊這個事務就可以認爲是一個大事務。
- 開發使用的語言
Java,php -- mysql ,oracle
- 應用場景
開源數據庫 --- 適用於互聯網項目
商業數據庫 --- 更適合企業級項目
mysql常用的存儲引擎：
表及字段的命名規則：
1、可讀性原則
表名使用大寫和小寫來格式化庫對象名字以獲得良好的可讀性。
字段使用下劃線來連接
2、表意性原則
對象的名字應該可以描述他所標識的對象
3、長名原則
儘可能少使用或者不使用縮寫，適用於數據庫名之外的對象
數據庫字段類型選擇原則：
舉例：
字段類型原則原則：當一個列可以選擇多種數據類型時，應該優先考慮數字類型，其次是日期或者二進制類型，
最後纔是字符類型。隊友相同級別的數據類型，應該有限選擇佔用空間小的數據類型。
char和varchar如何選擇？？
- char列的長度固定爲聲明的長度 ； varchar列的值爲可變長字符串，長度爲 L+1 字節 ；varchar需要額外的字節存儲大小
- 如果列中的最大長度小於50byte,一般考慮用char （一般不宜定義大於50byte的char類型列）
- 如果列中要存儲的數據長度差不多一致，應該考慮用char，否則用varchar
- 舉例：身份證號、手機號使用char ；
decimal 和 float如何選擇？？
- decimal用於存儲精確數據
- 由於float的存儲空間開銷比decimal，故非精確數據優先選擇float類型
時間類型如何選擇？？
使用int來存儲時間字段的優缺點：
- 優點：字段長度比datetime小
- 缺點：使用不方便，需要進行函數轉換
- 限制：之惡能存儲到2038-01-19
如何選擇主鍵？？
避免使用外鍵約束？？
- 降低數據導入的效率
- 增加維護成本
避免使用觸發器？？
- 降低數據導入的效率
- 可能會出現意想不到的數據異常
- 使業務邏輯變的複雜
關於預留字段
- 無法準確的知道預留字段的類型
- 無法準確的知道預留字段中所存儲的內容
- 後期維護預留字段所要的成本，同增加一個字段所需要的成本相同的
- 嚴謹使用預留字段
- 需要根據實際情況考慮
爲什麼要反範式化？？
舉例：
sql中select佔比更多，所以可以增加讀取效率，但是插入效率較低 。
反範式化優缺點：
- 減少表的關聯數量
- 增加數據的讀取效率
- 反範式化一定要適度（如果大量使用反範式化，會導致大量操作異常）
