新人交上来的表结构，我一般先看两处：每张表都有主键没有，商品表里存的是商品ID还是把名称价格一股脑抄了过来。看完就能判断这人是学过数据库设计，还是只会用可视化工具点点点。说到这儿就绕不开三大范式——教科书里的第一课，实际项目里却常常被「故意违反」，为什么？
范式解决什么问题
范式说白了就一件事：让一份数据只存一处。客户地址变了，只改客户表一行，订单里存的是客户ID，不用挨个订单去改地址。这从根上避免了改漏、改错，数据永远一致。订单、用户、库存这类核心业务表，范式要老老实实守着，这是底线，没有商量的余地。
什么时候可以不守
但读的场景多了，纯粹按范式来会出问题。举三个常见的例子：
- 订单里存商品快照。下单那一刻商品卖三千，你改价之后历史订单显示多少？订单明细必须冗余下单时的名称、价格、规格，这不是偷懒，是业务本身的硬要求。
- 列表页要显示作者昵称，每次都去join用户表，量大了查询明显变慢。冗余一份昵称进去，更新时多改一处，换查询快十倍，值。
- 统计类字段，比如文章表里的评论数，靠count实时算，不如每次评论时顺手加一，写入时多花一毫秒，读的时候省一次全表扫描。
判断标准就一条
冗余的字段，业务上允不允许「不一致」？商品快照要求的就是不一致，那就冗余；用户改了昵称，列表显示旧名字能不能接受？能接受就冗余，不能就老老实实join。范式是手段不是信仰，脱离查询性能空谈范式，和脱离数据一致性空谈优化一样，都是偏的。
再多说一个判断技巧：看这个字段是「事实」还是「描述」。下单时间、成交价格是事实，绝不能冗余出不一致的版本；商品标签、用户昵称是描述，晚几小时更新天塌不下来。事实走范式，描述可冗余，这句话不严谨但好用，团队里评审表结构时拿来当第一轮筛选，够用了。
两条建议：核心交易表按范式来，读多写少的展示场景允许合理冗余；动手前先想清楚「这个字段将来怎么更新」。拿不准数据库设计怎么取舍的，可以让比格网络这类有实际项目沉淀的团队先出一版设计稿再动工，比代码写一半推倒重来省太多了。
