数据库范式实战：从第一范式到BCNF，告别数据冗余与更新异常

很多同学学数据库范式，都是先从定义开始：第一范式要求原子性，第二范式消除部分依赖，第三范式消除传递依赖。定义背得滚瓜烂熟，可一到自己建表就完全用不上，甚至觉得范式就是考试专用知识点。我以前也这样，直到一次上线事故之后才明白，范式不是在给表结构添麻烦，而是在帮我们提前把脏数据、异常更新的坑填上。

这篇文章我打算用大白话把范式讲透。不会堆一大堆关系代数的符号，而是从实际建表场景出发，讲清楚每一级范式到底在防什么问题、怎么判断、以及真实项目里要不要严格遵守。不管你是刚学数据库的学生，还是写业务代码时碰到过 update 几百行历史数据的后端开发，这篇应该都能给你一些启发。

1. 为什么我一开始没搞懂范式：从一张“万能表”说起

1.1 一张“万能表”引发的线上事故

我第一次对范式有体感，是一次订单模块的线上事故。当时图省事，把用户信息和订单信息都塞进一张表，结构大概长这样：

sql复制CREATE TABLE order_info (
  order_id INT PRIMARY KEY,
  user_id INT,
  user_nickname VARCHAR(50),
  user_address VARCHAR(200),
  product_id INT,
  product_name VARCHAR(100),
  product_price DECIMAL(10,2),
  product_qty INT,
  order_time DATETIME
);

看着很方便吧？用户在哪个地址下的单、买了什么东西，一条记录全带出来。但接下来问题就来了。用户改名或者搬家之后，后台只要一触发改资料操作，程序就得去更新他名下所有历史订单里的 user_nickname 和 user_address。运气好时几千行，运气差时几十万行，一个 UPDATE 把整张表锁住，线上订单查询直接变慢，这就是典型的更新异常。

这还算轻的，更隐蔽的是插入异常和删除异常。比如一个新用户注册了但还没下单，在订单表里就没有位置放他的昵称和地址；再比如删除一条订单记录，如果这条订单是我们唯一存了某个商品名称的地方，那这个商品名称也跟着没了。一张表承载了太多本不该它承载的属性，数据不仅冗余，还处处是坑。

1.2 范式的本质不是理论而是约束

范式这个词听起来高大上，本质上就是一系列约束条件，用来回答一个问题：一张表里的数据该按什么规则组织，才能尽量避免重复、避免增删改时产生不一致。想象一下仓库库存管理：所有货都堆在一个区域，不分区不编号，进货找货都靠翻，短期看着省事，货一多就崩。范式就是把仓库划分成不同货架，每种货放在自己的位置上，还要在货架上写清楚这个位置到底该放什么。

为了好理解，可以把范式分成一级一级的关卡。第一关要求字段不能再拆，第二关要求在联合主键下每列都完全依赖主键，第三关要求非主属性之间不要互相依赖。每过一关，表的冗余和异常就会少一截。下面我就把这三关挨个讲清楚。

2. 第一范式到第三范式：每级规范到底约束了什么

2.1 第一范式：字段不能再拆

第一范式的定义一句话：表中的每个字段都应该是不可再分的原子值。这句话看起来简单，实际很多人在设计表的时候随手就犯了。

比如在设计一张用户表，为了省事，把一个用户的所有爱好存成一个字段：

hobbies 字段里一放就是多个值。表面上这只是格式问题，真正麻烦的是查询。想找出喜欢篮球的用户，SQL 得写成 WHERE hobbies LIKE '%篮球%'，带 % 前导的通配符查询基本走不了索引，数据量一上来就全表扫描。而且之后想拆出来做统计、做关联，都得写字符串拆分函数，又慢又容易出 bug。

正确的做法是把每个爱好拆成一行：