字段全塞一张表还是拆成几张，看改字段的有几个人

一张宽表六十个字段和三张分表各二十个字段，出来的数可以完全一样。决定要不要拆的不是字段数，是改字段的人有几个。

分岔点是这张表的字段有没有第二个团队会改

只被数据团队改的表，永远是一张宽表。运营要加一个"活动标签"、财务要加一个"含税成本"，改的都是同一张表的同一批字段，谁最后改谁负责，不需要拆。

一旦有两个团队各自要改字段，拆表就开始划线。运营的字段跟财务的字段互不相干，财务改自己的成本口径不会碰到运营的标签。分岔点落在"这张表会不会被两个团队同时改"上。

拆不拆，看改字段的是一个人还是两个团队

两条路摆在这张表里

宽表的好处是取数一次拉完，不需要 join。分表的好处是改动互不干扰，出错时能定位到是哪一张表。

选错的代价差在哪

A 路选错的代价是返工。宽表加一个字段要全表重算，18 万行重算一次 12 分钟不算什么，但它下面挂着五个下游报表，五个全要跟着重跑，两小时就这么没了。

B 路选错的代价是静默丢数。我见过一次拆表之后，日汇总比实际少 3%，查了三天，最后定位到某几个站点的 SKU 编码带后缀，join 的时候对不上，left join 变成了 inner join，那部分行直接消失了。一个月少算 24 万，而且报表上完全看不出异常。

退回来要花多少

宽表拆成三张，三天迁移加两周双写。两周里两张表同时写、两张表对不齐的风险要一直担着。拆完之后，宽表本身别删，留着做对账底稿。

分表合回一张，先用视图合，一天，业务完全不受影响。真要物理合回去，再花一周。

退成本最低的时间窗是刚拆完还没交接的那一周。这时候合回去只是把迁移脚本倒着跑一遍。

优劣在什么条件下翻转

表被改的频率会翻转优劣。字段一年改一次，宽表赢，拆表的收益永远等不到。字段每周都改，拆表赢，改动不互相覆盖。

另一条是出数方式。下游每次要全部字段做交叉分析，宽表赢，拆完要拼三张。分成上下游各自只看自己那几列，拆表赢。

两条都不该走的情况

三条同时命中，拆和不拆都别动：这张表只有两个字段会变、团队三个人以下、拆开之后没有共同的唯一键。最后一条最要命，没有唯一键的拆分，等于把一个数变成几个数，出错时没人说得清丢的是哪几行。

我自己在拆表这件事上判断错过一次。2018 年拆了四张表，三个月后又想合回去，因为运营要跨表做一次全字段交叉。最后是用视图糊过去的，那张宽表一直留着，半年之后没人知道它还有用。想清楚下游要几个形状，比想清楚表要几张重要。