宽表好问，星型好管。问数站在哪一边

公开路线对比里，有人用预置宽表把多表问题变成单表问题。问起来顺。管起来难：口径一变，宽表要重刷。星型模型管起来顺，问起来要走对关联路径。问数站哪边，是治理选择题，不是品味题。

高频卡片适合宽表

门店日成交这种每天都问的，宽表能少踩 JOIN。

指标平台适合星型

指标多、维度多、要复用时，宽表会爆炸。

不要两边各发明一套销售额

选边可以混用，口径必须唯一。两套销售额会比选错模型更糟。

一次完整的问法可以先写成下面这样：

从订单事实表连门店维度，按城市汇总昨天已支付金额。

落到语句上，草稿常常是：

SELECT d.city, SUM(f.pay_amount) AS gmv
FROM fct_orders f
JOIN dim_store d ON d.store_id = f.store_id
WHERE f.pay_time >= CURRENT_DATE - INTERVAL '1 day'
  AND f.pay_time < CURRENT_DATE
  AND f.pay_status = 'paid'
GROUP BY d.city;

星型并不高贵，宽表并不投机。谁能保住唯一口径，问数就站谁那边。

结构是地图，不是附录

公开实现文章把列出表、描述字段、抽样行、再执行写成四件工具。工具顺序不能倒。执行放第一位，等于闭眼过马路。

结构链接的失败，十之八九不是语法。是找错表、找错列、找错枚举值。注释、别名、示例值，是地图上的注记。注记质量决定问数上限。有人只补三十个核心字段的含义，可用程度就明显上升。这是最不时髦、也最管用的工作。

语义层是把指标、维度、关联路径写成中间层。个人没有引擎时，用字典和卡片冒充。没有这一层，每次提问都在重新发明销售额。宽表好问、星型好管，选边可以，口径必须唯一。

读完这一辑可以做什么

给十个核心字段写注释：时间、金额、状态、用户、地区、类目，外加四个你会用到的。注释里写计算、单位、示例值。写完再去问数，少猜一轮。

选边可以混用。两套销售额不可以同时叫销售额。