數據表的幾種的關系
- 一對一：學生和學生證
- 一對多：學生和班級
- 多對多：學生和課程
如何表示數據庫表之間的關系
- 使用外鍵：數據庫外鍵關系表示的其實是一種一對多的關系
- 一對一：外鍵+唯一
- 多對多：引入中間表，把一個多對多表示為兩個一對多
?
# 表設計的三大范式
? 所謂范式，即如何建立科學的，規范的的數據庫，需要滿足一些規范的來優化數據數據存儲方式的指導辦法。
第一范式（1NF）
- 每一列屬性都是不可再分的屬性值，確保每一列的原子性
- 合理的根據實際業務數據需求來決定屬性，合并相似或相同的列，避免冗余
假如有一個業務需求是：需要了解一批用戶的基礎信息（包括姓名，年齡，電話，詳細地址，以及根據地址明細進行分類），如果數據庫表設計如下，則不滿足第一范式：
? 以上實例中設計了地址，如果需求根據省，市進行分類則無法實現
【解決辦法】根據需求適當的將地址拆分為更原子的省市兩個屬性即可符合第一范式
第二范式（2NF）
- 需要確保數據庫表中的每一列都和主鍵相關，如果是聯合主鍵，則需要和所有主鍵均相關而不能只與主鍵和某一部分相關
- 在一個數據庫表中只能保存一種數據，不可以把多種數據保存在同一張數據庫表中
? 假設有表如下，學號和課程編號是聯合主鍵，但是，該表中，課程名稱和學號沒有任何關系，學生姓名和課程編號也沒有任何關系
【解決辦法】（1）提取學生表；（2）提取課程表；（3）建立學生課程關系表。
? 值得注意的是，學生表只存儲學生的基本信息屬性；課程表只存儲課程的相關屬性；學生課程關系表，只存儲學號（學生表主鍵）和課程編號（課程表主鍵）以及一些其他學生課程關系的屬性字段，并不存儲學生基本信息和課程相關信息，即可符合第二范式
第三范式（3NF）
- 確保數據表一個記錄中的數據都和主鍵直接相關，而不是間接相關，不能存在傳遞關系
- 屬性不依賴于其他非主屬性
? 假設有如下表，學號為主鍵，它存在 學號 --> 班級編號 --> 班級信息 這么一個主鍵學號與班級信息的傳遞關系，不符合第三范式
【解決辦法】（1）提取學生表；（2）提取班級表；
? 學生肯定在某一個班級中，所以班級編號可以作為學號(主鍵)的一個直接關聯屬性，但班級的其他信息應該放在以班級編號為主鍵的表中，即可符合第三范式。
遵循范式的優缺點
? 通過以上的了解，可以發現，范式規則有如下特點
- 結構合理，表含義容易理解及區分
- 冗余較小
- 但性能有所降低，多表查詢比單表效率低下
? 總結：數據庫表的設計，可以借鑒三大范式的指導辦法，同時也需要依賴于實際業務需求，良好的數據庫結構不僅可以提高開發人員的開發效率，降低開發難度，還可以提高數據庫查詢效率，給程序增加可變彈性，當冗余的代價小于查詢性能降低的代價時，就應該考慮冗余實現。
?
# 表設計的建議
1. 字段的原子性
? 保證每列的原子性，字段含義言簡意賅，高度概括。
? 能用一個字段表達清楚的絕不使用第二個字段，須要使用兩個字段表達清楚的絕不能使用一個字段
2. 主鍵設計
? 主鍵不要與業務邏輯有所關聯，最好是毫無意義的一串獨立不重復的數字
? 例如：使用UUID，或者將主鍵設置為AUTO_INCREMENT
? 根據數據庫設計三大范式，盡量保證列數據和主鍵直接相關而不是間接相關
3. 字段長度
? 字段長度盡量要比實際業務的字段大3-5個字段左右（考慮到合理性和伸縮性）
? 不要建比實際業務大太多的字段長度，，這是因為如果字段長度過大，在進行查詢的時候索引在B-Tree樹上遍歷會越耗費時間，從而查詢的時間會越久
4. 關于外鍵
? 盡量不要建立外鍵，保證每個表的獨立性。如果非得保持一定的關系，最好是通過id進行關聯
5. 動靜分離
? 做好靜態表和動態表的分離
? 靜態表：存儲著一些固定不變的資源，比如城市/地區名/國家(靜態表一定要使用緩存)。動態表：一些頻繁修改的表
6. 關于Null值
? 盡量不要有null值，有null值的話，數據庫在進行索引的時候查詢的時間更久，從而浪費更多的時間！可以在建表的時候設置一個默認值！
7. 預留表開關字段
? 設計一個單一字段去控制表是否可用，如 isValid: true/false
8. 刪除字段
? 數據庫是禁止使用delete命令的,一般都不會真正刪除數據，都是采用改狀態的方式，設置state字段，通過修改狀態賦予它是否有效的邏輯含義！
?
# 表設計的幾項原則
1. 職責分離原則
? 在設計的時候應當考慮到數據的產生，聚合使用等原則，每個系統干自己能干的事情，每個系統只干自己的事情：明確如下幾點：
（1）誰產生這個信息，就由誰對此數據負責
（2） 誰最經常使用這個信息，就由該系統來負責保存維護該數據
（3）遵守高內聚，低耦合的考慮：
2. 在線處理與分析分離原則
（1）為了保障線上數據處理的性能，將一些分析相關的數據及分析結果，應當使用單獨的庫來進行存儲，避免在數據分析的時候導致業務數據吞吐量下降，引起系統問題。
（2）專門用于存放離線報表數據，并提供線上數據查詢方法，建議將統計結果，匯總的數據都從在線處理數據庫中移走。
3. 事務與日志分離原則
（1）用戶生成內容和用戶行為日志要分開。系統本身預設的數據，記錄用戶身份及與功能相關的數據，和用戶的行為日志應當各自單獨存儲
（2）行為日志，需要做分析處理，并且由于時效性不宜存儲在MySQL中，后期維護就是地雷。
4. 歷史可追溯原則
? 在數據庫設計的時候為了保障數據是可追溯的，應當遵循一些簡單的約定，事后方便數據的查詢和統計：
（1）對于狀態數據，應當設計相應狀態的字段來保存該數據的最后狀態，同時記錄下來該數據的初始創建人，時間以及該數據的最后修改人和修改時間；
（2）針對需要跟蹤每次修改的數據，需要在數據發生變化的時候記錄一張日志表，用于記錄該數據發生變化的全生命周期。針對只需要關注關鍵字段變化的情況，則日志表中只需要記錄關鍵字段變化即可，但操作人，操作類型，時間應當準確記錄，日志表數據一旦生成不允許進行修改。
（3）針對所有歷史需要保留的數據則需要每次變化都生成一個新的版本，比如類目信息等，對原始數據永遠只做insert操作，不做delete及update操作。但這種情況僅限于極端數據歷史要求極高的情況下使用。
