简介：基于Java-EE的仓库管理系统数据库设计文档，面向软件工程、数据库相关课程设计及企业级仓库管理项目开发人员，旨在解决仓储系统中实体建模与关系梳理的核心问题。文档从系统分析入手，涵盖技术、经济、操作可行性分析，随后重点展开数据库设计，逐一给出货物、仓库、管理员、采购员、提货员五大实体的属性定义，如货物ID、名称、规格、数量、单价、供应商信息，仓库ID、名称、地址、容量等，并整合为整体ER关系图，清晰展示各实体间的关联，为后续物理表结构设计提供直接依据。资源包内仅包含1个doc文档，共5页，压缩后大小258KB，内容精炼、结构完整，可直接用于参考或修改。目前已有1669人学习浏览，适合正在做相关课题或项目设计的学生与开发者快速获取设计思路。
1. 基于 Java EE 的仓库管理系统，为什么说数据库设计是项目的生死线
看到一个基于 Java EE 的仓库管理系统时，很多开发者第一反应是去选框架、搭 Maven 工程、写 Controller。但真正让这个项目在三个月后变成维护噩梦的，往往是数据库设计。数据库设计阶段画出的 ER 图（实体关系图），直接决定了库存账目是否对得上、并发操作会不会串数据、报表查询能不能在可接受时间内跑完。我在某公司接手过一个仓库管理系统，早期开发图省事，把入库单和入库明细揉成一张表，结果对账时只能用脚本来凑数据，每次库存盘点都像在解谜。
这篇文章用一个完整的仓库管理系统数据库设计过程来讲透：怎么从仓库业务里识别实体、怎么画 ER 图、怎么把实体关系转成物理表结构、再映射到 Java EE 里的实体类与事务边界。适合正在做课程设计、毕设，以及刚入职需要接手企业仓储类项目的开发者。标题里的 .doc 指的是数据库设计文档本身——这类文档的核心内容就是 ER 图加数据字典，文档的深度决定了开发的顺畅程度。
2. 从业务调研到实体识别：数据库设计的第一张图如何诞生
2.1 仓储业务中实体关系图的核心实体怎么划
仓库管理系统的实体识别，核心是回答一个问题：系统需要记录哪些"独立存在且需要被追踪"的对象。常见做法是跟着业务流程走一圈——采购入库、生产领料、销售出库、库存调拨、盘点。顺着这条主线，第一轮识别出的实体通常有这些：供应商、物料（商品）、仓库、库位、入库单、入库明细、出库单、出库明细、库存台账、盘点单、盘点明细、用户（操作员）。
这里有一个容易被新手搞混的点：入库单和入库明细为什么要拆成两个实体。原因在于业务上它们是"一对多"的关系，一张入库单携带多个物料条目。如果把明细直接挂在入库单上，用一个字段去拼字符串存多个物料，那么后续统计"某个物料一共入库了多少"时，就只能做字符串截取，查询性能和数据准确性都会很糟糕。实体关系图的价值，就是把这种一对多的结构固定下来。
提示：实体的划分不必一步到位。我一般先画出业务主链上的实体，再通过第二轮的属性分析去补漏。比如"库位"这个实体，如果项目只需要记录物料存放在哪个仓库，不需要细化到货架层，就可以先合并到仓库里；但如果是精细化管理，就必须单独拆出来。
再考虑一个容易遗漏的实体：操作日志。仓库系统的每一次入库、出库、盘点都是需要追溯的，操作日志实体记录谁在什么时间对哪个单据做了什么动作。虽然它不像业务实体那样醒目，但后续排查问题、做审计时离不开它。在 ER 图里加上操作日志，能让整个设计在合规性上站得住脚。
2.2 属性字段的选择：给实体补全信息时的取舍原则
实体定下来之后，第二步是给每个实体补充属性。这里的原则我总结为三句话：能关联的用外键，能穷举的用字典，能推导的不要存。
先说外键。仓库管理系统里几乎每个业务实体都要带上"属于哪个仓库""由谁操作""对应哪个往来单位"这类关联信息。在设计图上，这些会表现为关系线，而在设计文档里要明确标注外键字段。
再说字典。入库类型（采购入库、退货入库、调拨入库）、计量单位（件、箱、公斤），这类取值有限的属性，在 ER 图里直接标注为字典项，不需要为每一种类型都建立一个实体。这样画出来的实体关系图更清爽，实现时也可以用一张数据字典表统一管理。
最后说推导字段。比如"库存余额"，这个值可以通过"入库总量 - 出库总量"推导出来。在 ER 图阶段不画它，在物理表设计阶段留一个冗余字段来存快照值。为什么？因为每次查询都实时计算累计值，在数据量上来之后查询会越来越慢，而用冗余字段在每次出入库时维护，查询时直接读字段即可。这是数据库设计里典型的"空间换时间"取舍。
仓库管理系统中的物料实体，最核心的属性包括：物料编码、名称、规格型号、计量单位、默认库位、安全库存量。物料编码的设计要特别注意——它必须是全局唯一的，而且一旦确定就不允许修改。我在某公司吃过这个亏：物料编码用了"类别前缀 + 流水号"，后来公司调整了物料分类，前缀全变了，导致历史单据全都对不上。后来定下的规矩就是：物料编码用纯流水号，不携带任何业务含义。
2.3 用 1:1、1:N、M:N 关系把业务规则固定下来
实体关系图的核心不在于画了几个方框，而在于关系线两端的基数标注。基数标注直接对应着业务规则：一个供应商可以供多种物料，是 1:N；一张入库单对应多个入库明细，是 1:N；一个物料可以存放于多个仓库，一个仓库可以存放多种物料，是 M:N——M:N 关系在物理实现上必须拆成中间表。
画关系线时有一个值得注意的业务坑：库存台账和出入库单据之间是什么关系。不少初学者会把库存台账画成和入库单直接关联，这是不对的。正确的思路是：入库单和入库明细记录了"这次进来了什么"，库存台账记录的是"现在仓库里有什么"。台账里的每条记录都是由多张入库单累积出来的结果。所以库存台账实体和入库明细之间不存在直接的引用外键，而是通过"物料 + 仓库 + 批次"这个组合维度关联起来。如果在 ER 图阶段就把这个关系理清楚，后面写库存更新的 SQL 就不会出现一条入库单要 UPDATE 多行台账的割裂问题。
还有一个 M:N 的典型场景：盘点。盘点单和物料之间是多对多——一张盘点单要盘多个物料，一个物料在多次盘点中都会被盘到。这个 M:N 关系在 ER 图里用"盘点单 - 盘点明细 - 物料"的桥接实体来表示，盘点明细上存放账面数量、实盘数量、差异数量。把这个结构画出来之后，"盘点差异报表"的实现思路就一目了然了。
3. 从 ER 图到物理表结构：概念设计与建表 DDL 的转换要点
3.1 概念模型转物理模型的规范流程与建表 DDL
ER 图画好后，下一步是把它转成物理模型——也就是具体的表、字段、类型、约束。我常用的转换流程是：每个实体变一张表，实体的属性变字段；1:N 关系在 N 端的表中加外键字段；M:N 关系生成中间表；1:1 关系视情况合并或者保留外键。这个流程说起来简单，实际操作中需要大量取舍，下面用入库单和入库明细直接演示。
-- 入库单主表 CREATE TABLE inbound_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, supplier_id BIGINT NOT NULL, warehouse_id BIGINT NOT NULL, inbound_type TINYINT NOT NULL COMMENT '1-采购入库 2-退货入库 3-调拨入库', status TINYINT NOT NULL DEFAULT 0 COMMENT '0-草稿 1-已审核 2-已入库', total_amount DECIMAL(14,2) NOT NULL DEFAULT 0, operator_id BIGINT NOT NULL, remark VARCHAR(255) NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_supplier (supplier_id), KEY idx_warehouse (warehouse_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='入库单主表';这段建表 DDL 把 ER 图上的"入库单"实体完整落成了物理表。order_no是业务单号，设置了唯一键，为了应对手工录入单据的场景；supplier_id、warehouse_id、operator_id都是外键逻辑关联，建表时先不设物理外键约束，理由在后面的避坑章节展开。inbound_type用TINYINT加注释来表示枚举值，而不是用字符串，这样既节省存储空间，又通过COMMENT保留了可读性。total_amount在这里是冗余汇总字段，每次明细表插入时同步累加，避免统计时全表扫描明细。
3.2 主键策略与关联外键设计：一张入库明细表的设计示范
入库明细表是仓库系统里最需要仔细设计的表之一。它承载着"一张单到底进来了哪些物料"的核心信息。主键策略上，我选择使用自增BIGINT作为物理主键，同时用"入库单号 + 物料编码 + 批次号"做业务唯一键。这样既保证了行级别的稳定标识，又防止了同一批次物料被重复录入。
-- 入库明细表 CREATE TABLE inbound_order_item ( id BIGINT NOT NULL AUTO_INCREMENT, inbound_order_id BIGINT NOT NULL, material_id BIGINT NOT NULL, batch_no VARCHAR(32) NULL COMMENT '批次号，无批次管理时可为空', quantity DECIMAL(14,2) NOT NULL COMMENT '入库数量', unit_price DECIMAL(14,4) NOT NULL COMMENT '单价，保留4位精度', line_amount DECIMAL(14,2) NOT NULL COMMENT '行金额 = quantity * unit_price', location_id BIGINT NULL COMMENT '上架库位', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_material_batch (inbound_order_id, material_id, batch_no), KEY idx_material (material_id), KEY idx_location (location_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='入库明细表';有一个参数需要注意：unit_price用DECIMAL(14,4)，而金额汇总字段用DECIMAL(14,2)。这是为了避免单价精度被金额精度绑架。比如单价 3.1415 元、数量 10 件，行金额是 31.42 元；如果单价也定义成两位小数，就只能存 3.14，最终汇总金额就会出现累计误差。Java EE 项目里对应实体类的BigDecimal字段，必须和这里的DECIMAL精度一一对应，否则 ORM 框架在做类型转换时会丢掉精度。
3.3 快照字段与审计字段：ER 图不会告诉你的表设计细节
前文说了冗余字段，这里给出完整的设计思路。库存台账表需要冗余什么？不只是数量，还包括"最近入库时间""最近出库时间"。这两个时间戳在生成库存报表时非常有用——想查"哪些物料超过 90 天没有出入库"，如果台账上没有这两个字段，就只能去 scan 所有明细表，数据量大时这个查询会非常痛苦。
-- 库存台账表 CREATE TABLE inventory_stock ( id BIGINT NOT NULL AUTO_INCREMENT, warehouse_id BIGINT NOT NULL, material_id BIGINT NOT NULL, batch_no VARCHAR(32) NOT NULL DEFAULT '', quantity DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '当前可用数量', locked_quantity DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '锁定数量：已下单未出库', last_in_time DATETIME NULL COMMENT '最近入库时间', last_out_time DATETIME NULL COMMENT '最近出库时间', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_wh_material_batch (warehouse_id, material_id, batch_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='库存台账表';locked_quantity这个字段是仓库系统里最容易在设计阶段漏掉的。它解决的是"下单但还没出库"这段时间的库存占用问题。比如销售订单审核通过后，仓库还没有实际发货，这时候这批货在台账上应该表现为"不可用"。如果没有锁定量字段，两个销售员就可能把最后一件货同时卖给两个客户，也就是常说的超卖。version字段是为乐观锁准备的，在后面的避坑章节会专门讨论并发场景。
审计字段（create_time、update_time）在不同业务里要求不一样。做财务对接的系统还要求有audit_time和audit_by，我习惯在每一张核心业务表上都加上create_by和update_by，用来记录操作人。这不是 ER 图上的实体字段，但在 Java EE 的实体基类里统一管理，省去每个表重复声明的麻烦。
4. 把 ER 图映射到 Java EE 持久层：实体类、JPA 注解与事务设计
4.1 JPA 注解映射实体关系：两端都要能导航才算画对了
有了物理表结构，接下来用 JPA 注解把表映射成 Java 实体。仓库管理系统的实体关系图在这个阶段要能被"双向导航"——从入库单能找到明细列表，从明细能找到所属的入库单。如果某个方向在业务里用不到，就不要在代码里加上对应的注解映射，否则会引入不必要的懒加载异常和性能开销。
@Entity @Table(name = "inbound_order") public class InboundOrder { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "order_no", nullable = false, length = 32) private String orderNo; @Column(name = "inbound_type", nullable = false) private Integer inboundType; @Enumerated(EnumType.STRING) @Column(name = "status") private InboundStatus status; @OneToMany(mappedBy = "inboundOrder", cascade = CascadeType.ALL, orphanRemoval = true) private List<InboundOrderItem> items = new ArrayList<>(); // getters and setters 省略 }@Entity @Table(name = "inbound_order_item") public class InboundOrderItem { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "inbound_order_id", nullable = false) private InboundOrder inboundOrder; @Column(name = "quantity", nullable = false, precision = 14, scale = 2) private BigDecimal quantity; @Column(name = "unit_price", nullable = false, precision = 14, scale = 4) private BigDecimal unitPrice; }@OneToMany(mappedBy = "inboundOrder")的含义是：关系的维护端在明细表那一侧，主表只做映射声明。cascade = CascadeType.ALL让保存主表时自动级联保存明细，但要注意——更新场景下全量级联是危险的。比如前端传来一个编辑后的明细列表，JPA 会先删掉旧的全部明细再插入新的，这在仓库单据上意味着历史痕迹丢失。更稳妥的做法是关闭orphanRemoval，自己在 Service 层做明细对比或者采用软删除标记。
4.2 DAO / Service 事务边界的划分：一个入库操作跨越几张表
仓库系统的事务边界设计比普通 CRUD 要讲究得多。一次入库操作至少要更新三类数据：插入入库单主记录、插入入库明细记录、更新库存台账数量。这三步要么全部成功，要么全部回滚，必须在一个事务里完成。但在 Java EE 分层架构中，事务不能开在 DAO 层——因为一次业务操作往往会调用多个 DAO 方法，每个 DAO 开一个事务会导致部分成功部分失败。
@Service public class InboundService { @Autowired private InboundOrderRepository inboundOrderRepository; @Autowired private InventoryStockRepository stockRepository; @Transactional(rollbackFor = Exception.class) public void confirmInbound(InboundOrder order, List<InboundOrderItem> items) { // 1. 保存入库单与明细 order.setItems(items); inboundOrderRepository.save(order); // 2. 更新库存台账：按仓库 + 物料 + 批次定位唯一一条记录 for (InboundOrderItem item : items) { InventoryStock stock = stockRepository .findByWarehouseIdAndMaterialIdAndBatchNo( order.getWarehouseId(), item.getMaterialId(), item.getBatchNo()); if (stock == null) { stock = new InventoryStock(); // 设置仓库、物料、批次等属性 } stock.setQuantity(stock.getQuantity().add(item.getQuantity())); stock.setLastInTime(LocalDateTime.now()); stockRepository.save(stock); } } }在这个 Service 中，@Transactional(rollbackFor = Exception.class)保证所有子操作共享同一个数据库连接和事务。rollbackFor必须显式指定，因为 Spring 默认只对RuntimeException回滚，而仓库系统里的业务异常（比如库存不足、单据已审核）经常用自定义受检异常抛出，不指定的话事务不会回滚，库存就被悄悄改掉了。
实际项目中我还会在更新库存之前先做一次SELECT ... FOR UPDATE加行锁。上面的代码用findBy...查询后修改再保存，是一个典型的"先读后写"操作，在并发环境下会出现丢失更新。后面避坑章节会给出完整的解决方案。
4.3 数据校验与数据库约束的双保险
实体关系图上的约束，比如"入库数量必须大于 0""物料必须存在于物料表中"，落到系统里需要两道防线：前端/Service 层做业务校验，数据库层做约束兜底。只靠一端都不够。我在某公司见过一个项目，校验只写在 JavaScript 里，后来有人绕过前端直接调用接口，传了一个负数入库，库存台账直接变成了负数。
public class InboundOrderItemValidator { public static void validate(InboundOrderItem item) { if (item.getQuantity() == null || item.getQuantity().compareTo(BigDecimal.ZERO) <= 0) { throw new BusinessException("入库数量必须大于0"); } if (item.getMaterialId() == null) { throw new BusinessException("物料不能为空"); } } }数据库层的兜底做法，是在表上增加CHECK约束。不过 MySQL 8.0.16 之前的版本不会执行CHECK约束，所以最常见的兜底是用DECIMAL类型本身加上UNSIGNED属性（仅限非负场景），以及用NOT NULL来约束必填字段。对于"数量不能为负"这种需求，如果在 Java EE 层用BigDecimal配合业务校验已经充分覆盖了误调用场景，就不必强求数据库的CHECK。在设计文档中，我会用数据字典的"校验规则"列把这两层写清楚。
5. 基于 Java EE 的仓库管理系统数据库设计避坑指南：五个典型问题
5.1 入库单与入库明细的一致性坑
有一回我接手一个仓库管理系统，现象是：入库单显示 5 条明细，但明细表里只查得到 3 条。导出的对账报表总是少数据。查了代码才发现，之前的开发人员保存入库单时用了两次独立的保存操作——先保存主表，再循环保存明细，每次 save 都是独立事务。保存到第 4 条时抛出异常，前 3 条已经提交，主表也提交了，于是数据库里就留下了"残缺的单据"。
原因是主表和明细表没有被纳入同一个事务边界，异常发生时无法回滚。解决方法是：把保存主表和保存明细放到同一个@Transactional方法里，并且在 JPA 的@OneToMany关系上配置cascade = CascadeType.PERSIST。另外我习惯在 Service 方法的入口处对明细列表做非空校验：即使事务是正确的，空明细列表也应该被拦截在业务层，不让它进入持久化流程。
5.2 库存余量字段引发的并发脏读
仓库系统做大了之后，几乎必然遇到并发问题。最常见的现象是：两个仓管员同时给同一个物料做出库，系统显示库存还剩 10 件，两个出库单各出 8 件，结果两单都成功了，库存变成了 -6 件。原因就是前面说的"先读后写"——两个事务读到同样的 10，各自减 8 后写回 2，最后一个写的人获胜。
解决方案我推荐两种组合使用。第一种是数据库层的悲观锁：
@Lock(LockModeType.PESSIMISTIC_WRITE) @Query("select s from InventoryStock s where s.warehouseId = :warehouseId and s.materialId = :materialId") InventoryStock findByWarehouseAndMaterialForUpdate(@Param("warehouseId") Long warehouseId, @Param("materialId") Long materialId);第二种是表结构中的version字段配合 JPA 的@Version注解做乐观锁。悲观锁适合出库操作这类竞争激烈的场景，因为必须确保"看到的就是最新的"。乐观锁适合盘点单确认、批次信息修改这类冲突概率低的场景。两种锁都不加是靠运气做开发，早晚要翻车。
5.3 多仓库多批次场景下的唯一键设计
现象：系统上线两个月后，发现某个物料在某个仓库的库存数量惊人对不上，一笔本来是入 A 仓库的单子，明细却串到了 B 仓库。原因出在唯一键设计：原本库存台账的唯一键只设置了material_id + batch_no，没包含warehouse_id。也就是说，同一批次物料在 A、B 两个仓库之间的台账记录被视为同一条。程序按"先查后插"的逻辑运行时，第二次插入时命中了唯一键冲突，代码里又没处理冲突，数据就更新到了错误的行上。
解决方法是三条线一起改：建表 SQL 的唯一键加上warehouse_id，实体类里@Table(uniqueConstraints = ...)同步修改，再写一个数据库迁移脚本把已有重复数据进行拆分修正。这个案例给我的教训是：ER 图阶段画"M:N 关系拆中间表"时，中间表的联合唯一键要把所有维度都列全——仓库、物料、批次，缺一个都是数据灾难。
5.4 删除策略：物理删除与逻辑删除的选择
有次做盘点差异调整功能，开发人员直接对盘点明细执行了DELETE操作。现象是：盘点差异历史查不到了，财务审计时拿不出原始差异记录。原因很简单——盘点操作在业务上有审计要求，任何调整操作都必须留有痕迹，物理删除把"账"给删没了。
仓库管理系统的删除策略我一般按三个等级判断：一是单据类数据（入库单、出库单、盘点单）只能做"作废"操作，也就是修改状态字段为已作废，禁止物理删除；二是基础资料（物料、供应商）在存在业务引用时不能删除，只能标记禁用；三是纯冗余数据（操作日志、临时计算表）可以物理删除，但也建议按月归档。在表结构中，用status或者deleted字段配合filter注解来实现逻辑删除。JPA 里可以用@SQLDelete和@Where注解统一拦截删除操作。
5.5 关联查询性能滑坡时的索引策略
仓库管理系统的查询大多是多条件组合：按仓库查、按物料查、按时间段查、按单据状态查。如果建表时只设置了主键索引和唯一键索引，一旦数据量超过三五十万行，联合查询就会明显变慢。有个场景让我印象很深：盘点报表查询关联了五张表，跑一次要 8 秒，页面上直接超时。
排查时用EXPLAIN看执行计划，发现三个问题：关联字段上没索引、状态字段是低选择度却放在了联合索引第一位、时间范围过滤没有走索引。解决方法是先按高频查询场景梳理索引：(warehouse_id, status, create_time)是报表查询的热点组合；然后在两个表关联的字段上确认索引类型一致，避免隐式类型转换。最后删掉冗余的重复索引——有些历史开发在同一个表上建了idx_warehouse和idx_warehouse_status，两个索引的左边前缀完全重复，后者没有实际作用还拖慢写入速度。
索引设计不是越多的越好。每个索引都会占用磁盘空间，并且增加INSERT/UPDATE的耗时。仓库系统里写入频繁的是库存台账和出入库明细，这两张表上的索引数量我会控制在 5 个以内，优先保证唯一键和核心外键，报表类查询索引放到只读的从库上或者通过定时汇总表解决。
6. 把 ER 图变成可持续维护的资产：数据字典与版本管理
6.1 数据字典的维护方式
ER 图画完、表建好、代码跑通之后，数据库设计文档的工作还没有结束。我在某公司维护过一个经历三代开发者的仓库管理系统，每一个接手的人都会先翻数据字典——哪个表是干什么的、每个字段什么含义、枚举值有哪些。数据字典维护的关键在于"更新及时"：每次改动表结构，都要同步更新字典文档。我现在的习惯是维护两个东西：一份字段级的数据字典表格，一份记录变更历史的变更日志。字段级的字典表格列这些内容——表名、字段名、字段类型、是否可空、默认值、业务含义、枚举值说明、关联表、校验规则。
很多团队嫌维护字典麻烦，用 Navicat 直接画表结构就完事。但表结构的COMMENT和完整的数据字典之间差距很大：COMMENT只写一句话，数据字典里要写清楚这个字段在不同业务场景下的特殊规则。比如locked_quantity字段，字典里会补充：销售订单审核通过时增加，出库完成时扣减，作废订单时回滚。没有这段说明，后来的人看到字段名根本不知道锁定量是怎么来的。
6.2 ER 图版本管理与变更评审流程
数据库结构变更在仓库管理系统里是一个高危险动作。我给出的建议是：每次 ER 图修改都必须走评审流程——变更提出人说明改动原因和影响范围，数据库负责人评估对现有数据的影响，确定迁移脚本方案后再执行变更。变更脚本要落入 Git 仓库，与 Java 代码的版本一一对应。执行的顺序是先备份，再执行迁移脚本，然后更新数据字典，最后发布应用代码。
一个值得培养的细节习惯：给每次数据库变更打一个标签，比如schema_v1.3_inbound_add_location_id。这个标签出现在 Git 提交信息、迁移脚本文件名、变更日志三处。仓库系统线上出了问题，查"是哪个版本的代码对应哪个版本的库结构"就非常快了。如果回滚代码但数据库没回滚（或者反过来），系统就会出现 JPA 映射的字段在表里不存在这种低级又致命的错误。
我自己也曾经跳过这个流程，以为加一个字段是小事，直接改了表结构没更新数据字典，结果一个月后另一个同事接手做功能，看到一个字段名猜了三天才弄明白它存的是什么。从那以后，数据字典的更新就变成了我提交通道里的强制检查项：没有同步字典的数据库变更，不允许合并到主分支。实体关系图是一张会生长的地图，不能画完就扔进文件夹不管，让这条地图保持和真实世界的同步，是仓库管理系统长期稳定运行的基本功。希望这篇关于数据库设计与 ER 图的实战拆解能帮到你，动手画图、建表之前先把上面这些坑过一遍，你的仓库管理系统会省下大量后期返工的时间。
本文还有配套的精品资源，点击获取
的算法优化与实战应用)