在规划数据库表结构时，数据库范式是我们经常遵循的设计原则，不过有时候为了提高查询效率，我们也会有意识地打破范式的约束。

今天我们就来聊聊在范式设计与性能优化之间如何权衡取舍。

1.范式

第一范式

表中的所有字段都应是最小的数据单元，不可再拆分。一个典型的例子是地址信息，如果直接存放“省份+城市+区域”的组合数据，就会违反第一范式的要求：

为了满足第一范式，可以将地址拆分成独立的字段来存储。

当然，这里只是为了举例说明，实际项目中更常见的做法是直接使用国家标准地区代码来保存地址信息。

第二范式

首先要满足第一范式，然后确保非主键字段必须完全依赖于整个主键，而不能只依赖主键的一部分。比如下面这个订单明细表的结构：

如果只用“订单ID”无法唯一标识记录，需要使用“订单ID+商品ID”作为联合主键。但“订单金额”这个字段实际上只与“订单ID”相关，与“商品ID”无关，这就违反了第二范式。我们可以通过优化表结构，将订单金额单独提取出来：

订单金额表：

查询时通过订单ID进行关联查询即可。

第三范式

在满足第二范式的基础上，表中的字段不能存在传递依赖，即不能通过其他非主键字段间接依赖于主键。再看下面的订单表，主键是订单ID：

“用户姓名”并不是直接依赖于“订单ID”，而是通过“用户ID”间接关联的，这就不符合第三范式的要求。我们可以将用户信息拆分成独立的表，查询时通过用户ID进行关联。订单表：

用户表：

BCNF 范式

也称为BC范式，在满足第三范式的基础上，不允许表中存在多个字段都可以作为主键的情况。比如下面这个仓库管理表：

如果一个仓库只能由一位管理员负责，而一位管理员也只能管理一个仓库，那么主键可以选用{仓库ID，存储商品ID}，也可以选用{管理员ID，存储商品ID}。这就违反了BCNF范式。我们可以将上表拆分成两个独立的表：仓库管理表：

仓库表：

4NF 范式

第四范式在第三范式的基础上，消除了表中的多值依赖关系。比如下面这个表虽然符合第三范式，但订单ID和产品ID之间存在多对多的关系。

可以将其拆分成三张表，订单产品关系表：

订单表：

产品表：

查询时进行三张表的关联操作。

2.优劣对比

从上面的介绍可以看出，范式是数据库设计的重要规范，主要有以下优势：

减少存储空间：同一实体的属性只在表中存储一次，减少了数据冗余，节省了存储空间；写入性能高：每个属性的插入、更新通常只需要操作一张表，操作的数据集小，效率更高；数据完整性：遵循范式设计，表中通过保存关联实体的主键来确保数据的一致性；去重操作少：没有冗余数据，就很少会用到distinct和group by这类耗时的查询语句。

但过度遵循范式设计，也会带来一些缺陷：

查询性能受影响：查询通常需要关联多张表，当关联的表数量较多时，JOIN语句会成为性能瓶颈；SQL语句复杂度提高：多表JOIN往往使查询语句可读性变差，遇到重构、迁移之类的工作，会带来很多额外工作量；对索引依赖更多：为了提高JOIN语句性能，往往需要在连接字段上建立索引。

正是由于严格遵守范式可能带来的这些缺点，在实际设计和开发中，我们往往会适当引入反范式设计，通过增加数据冗余来避免复杂的JOIN操作，同时通过对冗余字段建立索引来提高查询效率。其核心思路是用空间换时间。

反范式设计的优势在于简化查询语句，提高SQL执行效率，特别适合高并发读取的场景。

但在写入频繁的场景下，也会带来一些问题，比如因为要写多张表，增删改操作更复杂，很容易造成锁竞争，降低写入性能。同时也更容易导致数据不一致，增加维护难度。

3.使用建议

在我们的实际项目开发中，通常采用混合式的设计策略。

对于OLTP（联机事务处理）类型的应用场景，比如电商、ERP等写入较多的系统，可以考虑采用范式设计。

而对于OLAP（联机分析处理）的使用场景，比如报表、数据仓库等，需要处理复杂查询的业务，都是读取操作，可以考虑采用反范式设计。通常使用ELT工具将业务数据从关系型数据库抽取到数据湖仓，在湖仓构建反范式化的数据模型，用于业务数据查询和报表生成。