图 1：本文封面，天平就是范式设计的全部隐喻：无冗余对少联表，永远在做取舍。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料，与任何公司的当前招聘无关。三范式是数据库理论的老面孔，但面试官真正想听的是后半句：什么时候该违反它。只会背定义的人，解释不了为什么真实业务库里宽表遍地都是。
想象面试现场：「说说数据库三范式。——那你们项目里的表都符合三范式吗？为什么？」
第一范式：列不可再拆，一行一格一个值。
第一范式消除的是「重复组」。一张学生表把选修课塞在一个字段里存「数学,英语,物理」，就违反了 1NF：一个格子里装了多个值，查询、统计、更新全都别扭。修法是把课程拆成独立的行或独立的表。1NF 是地基中的地基，几乎没有正当理由违反。
第二范式：非主键列必须依赖整个主键。
2NF 消除的是「部分依赖」，只在联合主键场景下才有戏。设想一张选课表，主键是（学生 ID，课程 ID），里面还存了「课程名称」。课程名称只依赖课程 ID 这一半主键，和学生 ID 无关——这就是部分依赖。后果立竿见影：同一门课的名字在几千行里重复存了几千份，改课名要更新几千行，漏改一行数据就自相矛盾（更新异常）；一门还没人选的新课根本插不进来（插入异常）。修法是把课程信息拆到课程表，选课表只留两个外键和真正属于「选课」这件事的字段。
第三范式：非主键列之间不得互相决定。
3NF 消除的是「传递依赖」。员工表里存了部门 ID，又顺手存了部门名称和部门电话：部门名称由部门 ID 决定，部门 ID 由员工 ID 决定，部门信息隔着一层传递依赖于员工。后果同样经典：部门改名要扫全表，最后一个员工离职时部门信息跟着消失（删除异常）。修法是把部门拆出去。
那什么时候该违反？
范式化的收益是「数据只有一份真相」：更新异常、插入异常、删除异常全部消失。代价是查询要联表——数据散在多张表里，一次业务查询 join 三四张是常态。当读取路径变成性能瓶颈时，反范式化就登场了：把高频联查的字段冗余进主表、为报表预聚合出宽表，用「维护冗余的一致性成本」换「读取速度」。这就是为什么数据仓库与训练样本侧宽表遍地都是：分析型负载读多写少、查询模式固定，冗余的代价小而联表的代价大。关键纪律是：违反范式必须是带着维护方案的主动决策——冗余字段由谁写、什么时候同步、对账怎么对，都得有答案；无意识地冗余，只是把 bug 存进了数据库。
图 2：三级阶梯消什么、什么时候该反着走。
可能的追问与易错点。
「范式越高越好吗？」不是。三范式之后还有 BCNF 等更严的形式，但工程上到 3NF 通常就是收益与复杂度的平衡点，继续往上拆的边际收益骤减。「反范式化会不会丢数据一致性？」会引入风险，所以才需要配套机制：同步写、定时对账、以某张表为唯一真相源。易错点有三：一是把三范式背成名词解释，讲不出每种范式消除的是哪类异常；二是把「违反范式」当设计缺陷的同义词，其实宽表是分析场景的成熟实践；三是反范式化之后不做一致性维护，冗余字段慢慢漂成两个版本。还有一个常见混淆值得主动澄清：2NF 的部分依赖只在联合主键下存在，单字段主键的表天然满足 2NF——把它讲出来，说明你不是按名词顺序背的。
回到面试现场，建议的答题节奏：先用「消重复组、消部分依赖、消传递依赖」一句话各定义一级，每级配一个异常案例；然后主动翻到后半句——范式的代价是联表，读取瓶颈场景下反范式化是正确选择；最后补一句纪律：违反范式必须是带维护方案的主动决策。能讲清「什么时候不守规矩」，才算真懂了规矩。
你见过设计得最拧巴的一张表是什么样？欢迎分享。