很多数据团队都有一张传奇宽表。
一开始，它只是为了方便。业务每天都要看订单、用户、商品、渠道，数据开发觉得每次临时 join 太麻烦，不如做一张大宽表，把常用字段都放进去。于是第一版表很受欢迎，分析师不用再到处找字段，BI 看板也跑得更快。
然后事情开始变化。
这个部门要加一个活动标签，那个部门要加一个会员等级，产品要看新功能曝光，运营要看优惠券领取，财务要补一个结算口径。每个需求单独看都合理，每次改动也都不大。半年之后，这张表有了几百个字段，字段名越来越像历史地层：有旧口径、有新口径、有临时字段、有没人敢删的字段。
最麻烦的是，大家都在用它，但没人真正说得清它。
宽表不是不能做。问题在于，很多宽表一开始是为了解决效率，后来却变成了口径混乱的容器。
宽表失控，通常不是因为技术差
很多人复盘宽表问题时，会说当初模型设计不好。这个判断有时成立，但不完整。
在真实公司里，宽表变乱往往不是一次设计错误，而是一连串“看起来合理”的妥协。
业务急着上线活动，希望今天就能看到数据；分析师要临时验证一个假设，希望先加个字段；老板要一个新口径，希望下周会前能出数；旧系统没有下线，新系统又来了，两个口径都要保留。
每一次，大家都觉得先加上去吧。反正只是一个字段。
但数据建模最怕的就是“只是一个字段”。
字段不是孤立的。它背后有主题、粒度、口径、刷新周期、责任人和下游使用场景。一个字段加进宽表，如果没有想清楚这些东西，就会把复杂度留给未来。
未来迟早会回来收账。
第一条边界：主题边界
一张表首先要回答：它到底描述什么。
订单宽表描述订单，用户宽表描述用户，商品宽表描述商品，商家宽表描述商家。听起来简单，但很多表就是从这里开始变乱的。
比如订单宽表里加用户生命周期标签，看起来合理，因为订单分析经常要按新老用户切分。再加商品一级类目，也合理，因为订单来自商品。再加活动曝光次数，好像也合理，因为要分析活动效果。再加客服投诉状态，也能解释，因为投诉会影响退款。
如果一直这么加，订单表最后会变成“所有和订单沾边的东西”。
这就失去了主题边界。
主题边界不是说不能冗余字段，而是要分清主信息和辅助信息。订单宽表可以冗余用户类型、商品类目、渠道来源这些高频维度，但不应该承载用户画像的完整生命周期，也不应该承载活动过程的全部明细，更不应该把客服、履约、财务所有状态都塞进去。
