3、库存表设计范式：三范式详解、反范式化在库存中的实际应用

聊到数据库设计，范式是个绕不开的话题。我记得刚入行那会儿，总觉得范式是教科书里才用的东西，实际写代码谁管这个？结果呢，被一个库存对账的bug折磨了整整三天。嗯，从那以后，我再也不敢小看范式了。

今天咱们就聊聊库存表设计里的范式问题。说白了，范式就是一套「数据该怎么放」的规则。你遵守了，数据就干净、好维护；你不遵守，后期改起来想哭。

3.1 第一范式：字段不可再分

第一范式的要求很简单：每个字段都必须是原子值，不能再拆。

举个例子，有人喜欢把库存信息存成这样：

-- 错误示范：字段里塞了多个值
CREATE TABLE inventory_bad (
    product_id INT,
    warehouse_info VARCHAR(200),  -- 存的是 "北京仓,100件;上海仓,200件"
    ...
);

你看，这个 warehouse_info 字段里既有仓库名又有数量，还用了分号分隔。查询某个仓库的库存时，你得先拆字符串，再解析。性能差不说，还容易出错。

正确的做法是拆开：

-- 符合第一范式
CREATE TABLE inventory (
    id INT PRIMARY KEY,
    product_id INT,
    warehouse_id INT,
    quantity INT,
    last_updated TIMESTAMP
);

我在项目中遇到过有人把「供应商名称+联系方式」塞一个字段里，结果要按城市筛选供应商时，代码写得跟绕口令似的。所以我的习惯是：能拆就拆，别偷懒。

3.2 第二范式：消除部分依赖

第二范式是在第一范式的基础上，要求非主键字段必须完全依赖于主键。不能出现「只依赖主键的一部分」这种情况。

库存表里常见的问题是这样的：

-- 违反第二范式
CREATE TABLE inventory_partial (
    product_id INT,
    warehouse_id INT,
    product_name VARCHAR(100),   -- 只依赖 product_id
    warehouse_name VARCHAR(100), -- 只依赖 warehouse_id
    quantity INT,                -- 依赖 (product_id, warehouse_id)
    PRIMARY KEY (product_id, warehouse_id)
);

你看，product_name 只跟 product_id 有关，warehouse_name 只跟 warehouse_id 有关。它们俩并不完全依赖联合主键。这会导致什么问题？

• 数据冗余：同一个产品名存了多次
• 更新异常：改产品名要改好多行
• 插入异常：没有库存记录时，产品信息存不进去

正确的做法是拆成三张表：

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(100)
);

CREATE TABLE warehouses (
    warehouse_id INT PRIMARY KEY,
    warehouse_name VARCHAR(100)
);

CREATE TABLE inventory (
    product_id INT,
    warehouse_id INT,
    quantity INT,
    PRIMARY KEY (product_id, warehouse_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id),
    FOREIGN KEY (warehouse_id) REFERENCES warehouses(warehouse_id)
);

3.3 第三范式：消除传递依赖

第三范式要求：非主键字段不能依赖于其他非主键字段。说白了，就是不能有「A→B→C」这种传递关系。

库存场景里，我见过这样的设计：

-- 违反第三范式
CREATE TABLE inventory_trans (
    id INT PRIMARY KEY,
    product_id INT,
    warehouse_id INT,
    warehouse_city VARCHAR(50),  -- 依赖于 warehouse_id
    warehouse_manager VARCHAR(50), -- 依赖于 warehouse_id
    quantity INT
);

warehouse_city 和 warehouse_manager 其实是通过 warehouse_id 间接依赖主键的。这就是传递依赖。

我曾经在一个老系统里看到一张库存表，里面存了仓库的地址、电话、负责人、面积……十几个字段。每次改仓库信息，要扫全表。你说这得多疼？

解决方案还是拆：

-- 仓库信息独立成表
CREATE TABLE warehouses (
    warehouse_id INT PRIMARY KEY,
    warehouse_name VARCHAR(100),
    city VARCHAR(50),
    manager VARCHAR(50)
);

-- 库存表只存核心数据
CREATE TABLE inventory (
    id INT PRIMARY KEY,
    product_id INT,
    warehouse_id INT,
    quantity INT,
    FOREIGN KEY (warehouse_id) REFERENCES warehouses(warehouse_id)
);

3.4 反范式化：库存场景的实战选择

好了，前面讲了三个范式，听起来很完美对吧？但现实是残酷的。你想想看，库存系统每天要处理成千上万次查询，每次都要 JOIN 三四张表，性能能好吗？

所以，反范式化就派上用场了。说白了，就是故意违反范式，用空间换时间。

我举几个库存里常见的反范式化例子：

3.4.1 冗余字段：减少 JOIN

比如，查询库存时经常要显示产品名称和仓库名称。如果每次都 JOIN，查询会变慢。我的做法是：

-- 反范式化：冗余常用字段
CREATE TABLE inventory_denormalized (
    id INT PRIMARY KEY,
    product_id INT,
    product_name VARCHAR(100),   -- 冗余字段
    warehouse_id INT,
    warehouse_name VARCHAR(100), -- 冗余字段
    quantity INT,
    last_updated TIMESTAMP
);

这样查询时一张表搞定，速度飞快。代价是什么？更新产品名或仓库名时，要同步更新库存表。不过，产品名和仓库名很少变，这个代价可以接受。

3.4.2 预计算字段：避免实时计算

库存系统里经常要算「可用库存 = 总库存 - 锁定库存 - 在途库存」。如果每次都实时算，数据量大了扛不住。

我建议的做法是：

-- 增加预计算字段
CREATE TABLE inventory_with_available (
    id INT PRIMARY KEY,
    product_id INT,
    warehouse_id INT,
    total_quantity INT,
    locked_quantity INT,
    in_transit_quantity INT,
    available_quantity INT,  -- 预计算字段
    last_updated TIMESTAMP
);

每次更新总库存、锁定库存或在途库存时，同时更新 available_quantity。查询时直接取这个字段，不用再算了。

3.5 范式与反范式的平衡：我的实战建议

你可能会问：到底该用范式还是反范式？我的答案是：看场景。

我一般这样决策：

场景	推荐做法	原因
基础数据表（产品、仓库）	严格遵循三范式	数据一致性要求高，更新频繁
核心库存表	适度反范式化	查询频繁，需要高性能
报表/统计表	大胆反范式化	只读不写，追求极致性能
日志/流水表	范式化为主	写入频繁，避免冗余带来的更新开销

我曾经接手过一个库存系统，设计者把范式奉为圭臬，所有表都拆得特别细。结果呢？一个简单的库存查询要 JOIN 6 张表，页面加载要 3 秒。后来我做了反范式化改造，把常用的冗余字段加进去，查询时间降到了 200 毫秒。

嗯，这就是实战。理论要懂，但别被理论绑死。

3.6 本章知识体系

下面这张图帮你梳理了本章的核心逻辑：

这张图展示了从三范式到反范式化，再到实战平衡的完整路径。你设计库存表时，可以沿着这个思路走一遍。

---

公众号:蓝海资料掘金营，微信deep3321