0x00 前言
本篇的主題是關於數據模型的規範化和反規範化的討論，其實也是一種常見的維度建模的設計和業務使用便捷性的衝突。
問題：
在設計數據表的時候，是一個寬表好，還是多個維度表好？
0x01 討論
本話題的原始討論在github上，本文只選取部分給大家參考：https://github.com/dantezhao/data-group/issues/1
回答一：
數據倉庫每張表的搭建，主要依賴於這個表在整個數據倉庫中的作用和相關意義。首先要清楚這個表的存在是爲了解決那些問題，什麼角色使用，怎麼保證使用者儘可能好的體驗解決問題。從以上所提到的角度去看待問題，拆解以下幾點因素：
拆表情況下多張數據表的查詢SQL的編寫難度有多大，是否會出現爲了數據提取需要關聯多張表，並且需要提前知道各個表之間的關聯關係。如果使用這個數據的人員較多，每個人都需要先了解所需要多張表的關聯關係，然後才進行數據查詢，這樣是不是維度溝通成本較高，查詢體驗下降，影響使用者的工作效率？
多表關聯查詢的使用頻次有多高，將重複高頻的事情簡化，是不是更好？
查詢體驗上需要考慮多表關聯之後的查詢性能問題，如果一張表的內容過度，是否影響查詢速度？
多表關聯的合理性，不同的數據維度和內容與訂單表關聯，是不是會存在違背常理的坑存在。比如，數據字段的對應關係是一對一，還是多對多，是否會讓使用者忽略查詢數據時候的過濾限制條件。
數據的安全問題，每張數據表的安全範圍不同，合併成同一張表是面臨的是更大的權限開放。比如訂單表可能僅需要讓一部分人員知曉訂單信息，並不想讓他們知道供應商信息。
回答二：
結合我司的一些經驗來說說哈，我司會將數據用於各種各樣不同主題和緯度的報表,也會將數據用於數據挖掘做模型的，因此數據分成肯定是必要的，針對報表類的數據根據報表的不同反向劃分出不同的緯度表,這種方式其實就是將mysql業務庫的數據經過sql語句之後重新生成一張或者多張維度表,在這之中根據經驗會抽取出一個經常用的字段作爲公共字段放入公共層數據中,一些經常需要用到的度量值也會抽取到度量表中,那麼一些非開發人員來看數據的時候只要在頁面上簡單寫幾個sql語句就可以統計出數據來,比如月銷量,周銷量,日銷量這些。
若是機器學習模型的同學要數據的話,我們就只需要從維度表,度量表,事實表中抽取數據做成大寬表給他們了,由於模型做的比較少,對於大寬表的經驗比較少,暫時只能來一個模型數據的需求,單獨寫sql語句去抽取。
0x02 補充
這個問題，從本質上來講。想討論是數據模型設計裏面的規範化和反規範化的問題。
從規範化的角度來講，數據倉庫的設計者是希望越規範越好，因爲這樣會減少數據的冗餘，而且也便於模型的擴展。從反規範化的角度來講，數據倉庫的使用者是希望使用越方便越好，他們並不太關係規範不規範冗餘不冗餘，只要用着方便就好。
這種情況在工作中是十分常見的，那麼該怎樣來解決它？下面有兩個思路：
兩種方式都存。雖然，這樣看起來會佔用更多的存儲空間，但不失爲一種合適的解決方案，因爲寬表是通過別的表拼接而成的，因此寬表的存儲週期是可以短一些。
只存多個維度表，通過視圖來創建寬表。這種方式適合於寬表的查詢次數較少的情況。比如在Hive中，寬表其實只是爲了計算出來之後導入Es等系統中供其它系統查詢，那麼久沒必要存儲一份寬表，直接通過視圖來封裝就可以。
另外，數據倉庫的設計，往往不能是以計算出幾張表就結束了，我們更應該提供的是數據服務，讓使用方都通過服務的方式來訪問我們的數據，而不是簡單地將表暴露出去。當我們以數據服務的方式提供數據的時候，不管是易用性還是安全性都更容易得到滿足。
0xFF 總結
感謝 Joker 和 Alan 的回答，感謝 Rebie 的整理，感謝木東居士的總結（自己感謝自己，^_^）。
本文是18年話題討論整理而來的文章，也算是數據百問系列的一篇，內容還不算過時，重新發出來供大家參考
熱門文章
【您的在看，我的莫大鼓勵】
