昨天面對某客戶域做表關聯的時候發現了。
有兩張相同內容的主表。但是表的設計結構並不相同：
（每個領域都有主表，每次往這個領域（庫）新增新錶的時候一般都會join 主表，從而有唯一的主鍵id）
這兩個表提供了這個領域的主鍵（id）.
在這個+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id | int | |
| name | string | |
| phone | string | |
| gender | string | |
| cardno | string | |
| age | string | |
| school | string | |
| quora | int | |
目測有60個字段這是一張寬表.
+------------+------------+----------+--+
+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id | int | |
| value1 | string | |
| type1 | string | |
| value2 | string | |
| type2 | string | |
| age | string | |
| school | string | |
| quora | int | |
目測有不到10個字段
+------------+------------+----------+--+
這是一張窄表
select type1,type2 from thistable group by type1,typ2;
發現型別資料有14種類左右
這樣就相當於把第乙個寬表的資料（可能剔除了不重要的字段）然後完全放開，行數暴增。
每次都要從其他表抽取資料關聯這個表id(唯一主鍵)，比如這個第三方表名字叫第三方客戶資訊 沒有id這列（畢竟id列是我們在自己的系統自己生成的），
只有使用者名稱和手機號+（第三方提供的字段（比如一周洗幾次澡）），我們用name+ phone去作為join on的條件關聯主表窄表，得到新的有主鍵的表。
select id ,max(a.欄位) from 第三方表 a
join
(select id,value1 as phone,value2 as name from 主表窄表 where type1=『mobile_phone』 and type2='name' group by id,value1,value2) b
on a.phone=b.phone and a.name=b.name
group by id.
note:上面的group by 的作用主要是為了去重。
但是為什麼這樣設計？這又是對記憶體和計算效率（時間）之間的權衡
應該是減少對記憶體的需求。因為join關聯必定要生成乙個中間表。如果是寬表記憶體太大，但是窄表犧牲了關聯效率。畢竟行數倍增原來十多倍。關於join的原理請看我另乙份部落格。
年前和專案老大聊了一會。他設計這個報表。感覺大佬的想法很nice。
資料倉儲 事實表
事實表分成三種 事務事實表 週期快照事實表 累計快照事實表 官方定義是 發生在某個時間點上的乙個事件。比如以訂單為例 下單是乙個事實 付款是乙個事實 退款是乙個事實，所有事實的累計就是事務事實表 如果需要對某一天或者某個月的資料進行分析，那麼可以使用週期快照事實表，比如 以天舉例，財務報表一般都是週...
資料倉儲 維度表
維度建模將業務抽象成事實和維度兩個概念。維度建模的核心是對齊維度。所以維度表的一致性是很重要的！維度表是如何進行處理的呢？穩定的維度表。比如 時間維度表 這種維度表的屬性是穩定的，不需要做天的全量快照資料，直接匯入一次即可 緩慢漸變維 維度會隨著時間發生緩慢的變化。比如 使用者維度表 資料量很大，但...
資料倉儲 DWS層之使用者行為寬表
為什麼需要使用者行為寬表？把每個使用者單日的行為聚合起來組成一張多列寬表，以便之後關聯使用者維度資訊後，進行不同角度的統計分析。建立使用者行為寬表 drop table ifexists dws user action create external table dws user action us...