供应链系统数据模型怎么设计？核心表、状态历史与数据质量

核心实体关系：从订单到履约的数据骨架

供应链系统的数据模型围绕几个核心实体展开，这些实体之间的关联决定了系统的处理能力和数据一致性。最常见的核心实体包括采购订单、库存、发货单、收货单和供应商主数据。

采购订单（Purchase Order）是起点，它包含订单头（供应商、日期、总金额）和订单行（物料、数量、单价）。订单行必须关联到物料主数据，而物料主数据又关联到供应商。这种多对一的关系在设计时需要注意：订单行不能直接引用供应商，必须通过订单头间接关联，否则会出现供应商不一致的异常。

库存表（Inventory）记录每个物料在仓库的数量和位置。库存表通常设计为多仓库模式，每个仓库有独立的库存记录。库存表的核心字段包括物料ID、仓库ID、可用数量、在途数量、锁定数量。这些字段需要实时更新，因此并发控制是重点。建议使用乐观锁或行级锁，避免在事务中长时间持有表锁。

发货单（Shipment）和收货单（Receipt）是库存变动的凭证。发货单减少库存，收货单增加库存。这两张表都应该引用采购订单的行ID，形成完整的追溯链。如果系统支持分批收货，收货单需要支持多行，每行对应一次收货。

供应商主数据（Vendor Master）相对稳定，但需要包含信用等级、交货周期、合作状态等业务字段。这些字段会影响采购订单的审批流程和交货期望。供应商表的设计要预留扩展字段，因为不同行业的供应商属性差异很大。

还有一个容易被忽略的实体是合同（Contract）。合同可以关联多个采购订单，规定价格、付款条件和交货条款。合同表的设计要支持版本管理，因为合同条款可能中途变更。

这些核心实体之间的关系可以用外键约束来保证数据完整性，但在高并发场景下，外键会影响写入性能。一个折中方案是在应用层维护引用关系，数据库只保留索引而不设置外键约束。这个决策需要根据系统的并发量和团队能力来权衡。

状态历史记录：为什么必须独立建表

供应链中每个核心实体都有状态，比如采购订单的状态从“草稿”到“已审批”再到“已发货”。很多系统直接在业务表里放一个状态字段，更新时覆盖旧值。这种做法在简单场景下可行，但一旦需要追溯历史状态变化，就会丢失信息。

状态历史必须独立建表，原因有三。第一，业务审计要求。供应链涉及资金和物权转移，如果出现纠纷，需要证明某个时间点订单处于什么状态。第二，流程分析需要。通过状态变化的时间差，可以计算每个环节的处理时长，找出瓶颈。第三，异常排查。如果订单卡在某个状态，历史记录能帮助定位是哪个操作或系统节点出了问题。

状态历史表的设计模式是：主表ID（如采购订单ID）、旧状态、新状态、操作人、操作时间、备注。这个表只插入不更新，数据量会随着时间增长，因此需要合理的分区策略。建议按月份或季度分区，并定期归档超过一年的数据。

索引方面，状态历史表需要两个复合索引：一个是(主表ID, 操作时间)，用于查询某个订单的状态变化；另一个是(操作时间, 新状态)，用于统计分析，比如统计每天进入“已发货”状态的订单数。

还有一个细节：状态变更的原子性。修改主表状态和插入历史记录必须在同一个事务中完成，否则会出现状态不一致。如果使用分布式事务，需要引入事务协调器或采用最终一致性方案，但后者会增加业务复杂度。

状态历史记录不应该存储冗余的业务字段。有些团队会把整个订单的快照存入历史表，导致表体积膨胀，查询变慢。正确的做法是只记录状态变化本身，业务字段的变更通过专门的变更日志表来记录。

索引策略：覆盖查询模式而非盲目建索引

供应链系统的查询模式相对固定，主要包括：按订单号查询、按供应商查询、按日期范围查询、按状态查询、按物料查询。索引设计应该优先覆盖这些高频查询。

订单号查询通常是等值查询，因此在订单号字段上建立唯一索引即可。但注意，订单号可能包含字母和数字，如果使用UUID作为订单号，索引的随机写入会导致B+树频繁分裂，影响性能。建议使用雪花算法生成的ID，保持趋势递增。

按供应商查询通常需要结合日期范围，比如“查询某供应商上个月的所有订单”。这种情况下，复合索引(供应商ID, 订单日期)比单独建两个索引更有效。同样，按物料查询库存变动时，复合索引(物料ID, 变动时间)能避免回表查询。

状态查询在供应链中很常见，比如“查询所有待审批的订单”。但由于状态值少（通常不超过10种），单独建索引的区分度不高，优化器可能选择全表扫描。这种情况，可以结合其他筛选条件，比如“待审批且创建时间在最近7天”，让索引(状态, 创建时间)发挥作用。

索引不是越多越好。每个索引都会增加写入开销，对于高频写入的表（如库存变动表），索引数量应控制在3个以内。一个经验是：在开发环境用慢查询日志找出执行时间超过100毫秒的SQL，然后针对性地建索引，而不是预先建一堆索引。

还有一个常见问题是联合索引的顺序。复合索引的最左匹配原则决定了字段顺序：区分度高的字段放在前面。比如(供应商ID, 订单日期)，供应商ID的区分度通常高于订单日期，所以放前面。

对于分区表，比如状态历史表，分区键的选择很重要。如果大多数查询都按时间范围进行，分区键应该使用时间字段。如果查询经常跨分区，分区反而会降低性能，此时应该使用全局索引。

扩展字段：三种方案的优劣与选择

供应链系统的业务需求经常变化，比如某个客户需要记录“到货温度”，或者某个行业需要“批号”字段。如果每次都在主表中加字段，会导致表结构频繁变更，影响系统稳定性。因此，扩展字段的设计是数据模型中的关键决策。

方案一是使用JSON或JSONB字段。PostgreSQL的JSONB支持索引和部分查询，灵活性最高。缺点是JSON字段的校验在应用层，数据库无法保证数据类型正确。另外，JSON字段的查询性能不如普通字段，不适合作为高频筛选条件。

方案二是预留备用字段。在表中预留10到20个字符型、数字型和日期型字段，比如ExtraChar1到ExtraChar10。这种方案简单直接，但字段含义不明确，维护成本高。新接手的人不知道某个备用字段在用什么业务含义，容易误用。我在一个项目中见过备用字段被三个不同功能同时使用，最终导致数据混乱。

方案三是使用EAV（实体-属性-值）模式，即独立的扩展属性表。主表ID、属性名、属性值、数据类型。这种模式最灵活，可以支持任意数量的扩展属性，但查询复杂，需要做行转列操作。对于供应链系统，如果扩展属性数量多且查询频率低，EAV模式是可接受的。但如果扩展属性需要参与复杂的业务逻辑（比如根据扩展字段计算价格），EAV会带来巨大的性能开销。

我的建议是：如果扩展属性数量少（少于20个）且业务稳定，使用JSONB字段；如果扩展属性数量中等且查询频率低，使用EAV模式；如果业务变化频繁但属性数量可控，可以结合使用，比如主表存核心字段，EAV表存扩展属性。无论哪种方案，都需要在文档中明确每个扩展字段的业务含义和使用范围。

数据质量：从源头到治理

供应链系统的数据质量问题往往来自三个源头：人工录入错误、系统间数据同步延迟、业务规则理解不一致。

人工录入错误最常见，比如供应商名称写错、数量单位不一致。解决方案是在录入时做校验。采购订单的数量字段必须是正数，单价不能为负数，日期不能早于当前时间。这些校验逻辑应该在数据库层也做一份，因为应用层的校验可能被绕过。使用CHECK约束可以保证基本的数据完整性。

系统间数据同步延迟会导致库存数据不一致。比如ERP系统更新了库存，但供应链系统没有及时同步，导致超卖。解决方法是引入消息队列，保证数据变更的最终一致性。同时，在关键业务操作（比如发货）前做数据校验，如果发现库存不一致，中断操作并告警。

业务规则理解不一致体现在字段含义的歧义上。比如“可用库存”在不同部门可能含义不同：仓库认为在库的才是可用，销售认为已下单未发货的也算可用。这个问题需要通过数据字典和业务术语表来解决。在数据模型中，每个字段都应该有明确的业务定义，并且这些定义需要业务方和开发方共同确认。

数据治理不仅仅是技术问题，更是管理问题。一个有效的方法是设立数据所有者（Data Owner），每个核心实体指定一个业务负责人，负责数据质量的监控和改进。技术层面，需要建立数据质量监控平台，定期扫描数据，发现异常（比如孤立订单、负数库存）并生成报告。

在SystemDo的项目经验中，我们发现供应链系统的数据质量提升往往是从一个具体的痛点开始的，比如某个客户的退货率异常高，追查发现是收货环节的数据录入错误。解决这个具体问题后，再逐步建立全面的数据治理机制，而不是一开始就追求完美。

风险与权衡：设计决策中必须考虑的因素

数据模型设计没有银弹，每个决策都有取舍。

第一个风险是过度设计。有些团队为了追求灵活性，一开始就使用EAV模式或大量JSON字段，导致查询性能下降，开发复杂度增加。正确的做法是从核心需求出发，先设计最简模型，遇到扩展需求时再逐步演进。

第二个风险是忽略并发。供应链系统经常有大批量操作，比如批量导入采购订单、批量发货。如果数据模型没有考虑并发性能，这些操作可能导致死锁或超时。解决方案是控制事务粒度，避免长事务，以及使用批量处理接口而非逐条处理。

第三个风险是数据冗余。为了提高查询性能，有些设计会冗余存储一些字段，比如在订单行中冗余物料名称。这确实能减少关联查询，但带来了数据一致性问题：物料名称变更后，历史订单的名称不会自动更新。如果业务要求历史订单保持当时的物料名称，这种冗余是合理的；否则，应该通过关联查询获取最新数据。

第四个风险是忽略归档策略。供应链数据增长很快，如果不做归档，查询性能会逐年下降。归档策略应该在数据模型设计阶段就考虑，而不是等到系统变慢后再处理。常见的做法是将半年以上的数据迁移到历史库，或者使用冷热数据分离的存储方案。

成本方面，数据模型设计本身不产生直接成本，但会影响后续的开发、维护和硬件成本。一个好的数据模型可以减少50%以上的开发返工，而一个糟糕的数据模型可能导致系统无法上线。因此，在设计阶段投入足够的时间是值得的。

周期方面，核心数据模型的设计通常需要2到4周，包括业务调研、实体关系设计、字段定义和评审。如果业务复杂或者涉及多个系统集成，周期可能延长到6周。这个时间不包括开发实现。

最后，数据模型设计是一个持续优化的过程。系统上线后，通过监控慢查询、分析数据异常、收集业务反馈，不断调整索引、扩展字段和校验规则。没有一劳永逸的数据模型，只有不断演进的系统。

以上是供应链系统数据模型设计的核心要点。从实体关系到状态历史，从索引策略到扩展字段，再到数据治理，每个环节都需要结合具体业务场景做出权衡。希望这些经验能为你的项目提供参考。