| 一、前言 |
1.1 關係型數據庫
數據庫關係型模型的概念最早由“關係數據庫之父”之稱的埃德加·弗蘭克·科德（Edgar Frank Codd或E. F. Codd）博士提出，1970年，身爲IBM的研究員的他在刊物《Communication of the ACM》上發表了題爲大型共享數據庫的關係模型的論文，首次提出了數據庫的關係模型的概念，奠定了關係模型的理論基礎。
本文以MySQL爲例介紹數據庫表結構的設計。
1.2 數據庫的優化模型
一般來說，日常工作中硬件和系統配置不是我們關注的重點，這些錢都就可以解決，我們關注最多的是數據庫表結構的設計和SQL級索引的優化。在大數據時代，這些理論同樣適用，在Hive和HBase中分別有表結構設計和RowKey設計，無論使用其他第三方SQL語言，比如，HQL、Phoenix、SparkSQL或Presto等，SQL及索引的優化是永恆的話題，這裏我們主要討論數據庫表結構的設計。
1.3 關係型數據庫設計的思路
一般地，設計思路包括如下兩個主要思路：
- 二維表
- 四個範式
- 業務相關的問題
其中，二維表很容易理解，二維即指行和列，不做細述，以下將詳細討論四個範式和工作中的業務問題。
| 二、四個範式 |
2.1 第一範式：不可再分
當表中字段存在可再分情況時，對其進行拆分。
舉例
2.2 第二範式：屬性完全依賴於某個候選鍵
簡單地說，第二範式滿足如下兩點要求：
- 每個表必須有唯一鍵；
- 主鍵是唯一標識。
2.3 第三範式：屬性不依賴於其它非主屬性
非主屬性是指不在任何碼（主碼和候選碼）中出現的屬性。
當屬性依賴於其他非主屬性時，應進行拆分。
舉例
未拆分前，屬性Level依賴於非主屬性Score，無法適應多變的業務，這種設計較爲死板，拆分後可靈活更改各個科目對應的level屬性，較爲靈活，適用於多變的業務。
2.4 第四範式：禁止非主鍵列和其他非主鍵列一對多關係
在同一張表中，非主鍵的列與非主鍵列存在一對多的關係會造成存儲大量的冗餘字段，當出現這種狀況時，應進行合理拆表。
舉例
在考試分數等級表中，Grade和Subject存在一對多的關係，浪費了存儲空間，且會降低查詢效率，拆分後業務的可擴展性更大，也節省了不必要的冗餘信息存儲所浪費的空間。
| 三、業務相關問題（撕逼） |
3.1 產品經理那些不能相信的話
- 這個屬性值
只有一個，這個只有一種情況… - 這就是個
小項目，不用搞那麼麻煩，趕緊做好上線，後面再說…
建表後隨着項目的迭代，後期重新設計表結構成本較高，開發需要修改代碼邏輯，數據庫中已存在的數據要做遷移和二次導入。良好的表結構設計可以幫我們避免很多問題，也會使整個項目更健壯。
3.2 有些還是能信的
- 這個項目每月訪問量預計
百萬，甚至千萬 - 日活
上億
如果聽到這種話，應該慶幸，這個是鍛鍊的機會，珍惜這樣的機會，做好表結構的設計及其他優化工作，這些以後都是財富。
| 四、 總結 |
綜上所述，表結構的設計是數據庫優化中至關重要的環節，需要認真謹慎對待，在遵守四大範式的前提下，充分考慮業務未來的可擴展性，適應未來業務變化，促進系統更加健康健壯。
- 本文借鑑了公司內DBA的分享，感謝DBA的指導；
- 能力有限，歡迎指錯交流。
歡迎關注個人微信公衆號WaltSmithML或新浪微博WaltSmith，公衆號提供機器學習、深度學習、Hadoop、Spark、Python、數學知識等免費視頻教程。本人目前工作主要負責智能推薦和NLP。非常歡迎一起交流學習哈，除了學習，還可免費幫忙download論文或者書籍
♥♥♥歡迎關注微信公衆號: 數學與機器學習♥♥♥
♥♥Python機器學習QQ羣♥♥
