有時候在面試的時候，有的面試官可能就問你數據庫方面的一些知識。
有沒有獨立做過項目啊，
那你是怎麼設計數據庫的呢？
這裏就不得不面對一個問題：
建表方面，你可以考慮下，你項目是用三範式還是反範式，理由是什麼？
官方的描述：
1NF:
無重複的列.表中的每一列都是不可分割的基本數據項.
2NF:
屬性完全依賴於主鍵.
3NF:
屬性不傳遞依賴於其它非主屬性.
非主鍵列必須直接依賴於主鍵，而不能傳遞依賴。
即不能是：非主鍵A依賴於非主鍵B，非主鍵B依賴於主鍵.
那什麼是反範式呢？
反範式：
反範式化指的是通過增加冗餘或重複的數據來提高數據庫的讀性能。
例如：在下面中的user_role用戶-角色中間表增加字段role_name。
反範式化可以減少關聯查詢時，join表的次數。
三範式詳細說明：
1. 第一範式
確保數據表中每列（字段）的原子性。
如果數據表中每個字段都是不可再分的最小數據單元，則滿足第一範式。
例如：user用戶表，包含字段id,username,password
2. 第二範式
在第一範式的基礎上更進一步，目標是確保表中的每列都和主鍵相關。
如果一個關係滿足第一範式，並且除了主鍵之外的其他列，都依賴於該主鍵，則滿足第二範式。
例如：一個用戶只有一種角色，而一個角色對應多個用戶。則可以按如下方式建立數據表關係，使其滿足第二範式。
user用戶表，字段id,username,password,role_id
role角色表，字段id,name
用戶表通過角色id（role_id）來關聯角色表
3. 第三範式
在第二範式的基礎上更進一步，目標是確保表中的列都和主鍵直接相關，而不是間接相關。
例如：一個用戶可以對應多個角色，一個角色也可以對應多個用戶。則可以按如下方式建立數據表關係，使其滿足第三範式。
user用戶表，字段id,username,password
role角色表，字段id,name
user_role用戶-角色中間表，id,user_id,role_id
像這樣，通過第三張表（中間表）來建立用戶表和角色表之間的關係，同時又符合範式化的原則，就可以稱爲第三範式。
我們項目中基本符合三範式的規則，
好像不存在反範式，
如果有很多的關聯查詢，我們會將數據組合成一個大的document，然後保存在非結構數據庫中，如mongoDB。
然後每天做定時任務同步數據到mongoDB中，
查詢的時候直接查mongo就可以了。
其實這裏也有不好的地方，因爲數據庫表的各種關係存在，因此在同步的時候，同步先後問題，
各種判斷比較複雜，導致我們數據時有時無的會丟失，在mysql中存在，同步到mongo中就丟失，
導致數據不一致。只能寫一個接口手動強制同步。
目前我們項目還沒有解決這種同步出錯的問題。還是上面這種處理方式。
應該是有一些好的同步插件來做這種同步，
例如，mysql同步到es的logstash插件。
所以這個同步這塊還是可以優化的。