2. 食品批次追溯数据模型设计

批次追溯看板能否真正回答“这批货从哪来、到哪去、中间发生了什么”，取决于底层数据模型是否把批次、物料、成品和供应链事件组织成可查询、可回溯的结构。本节围绕四个设计决策展开：批次编码规则、物料与成品的关联方式、生产/质检/仓储/物流四类事件的建模，以及时间序列与关系模型的选择。

一、批次编码规则：让编码本身携带可解析信息

批次编码是追溯链的主键，也是现场人员最常接触的标识。推荐采用“分段定长 + 语义前缀”的结构，例如：

格式：{工厂码2}-{产线码2}-{物料类别2}-{生产日期YYMMDD}-{班次1}-{流水号3}
示例：SZ-03-RM-250418-A-017
含义：深圳工厂 / 3号产线 / 原料类 / 2025-04-18 / A班 / 当日第17批

设计要点有三。第一，日期段必须使用生产日期而非录入日期，否则跨零点班次会产生歧义。第二，流水号按“工厂+产线+日期+班次”维度每日重置，避免全局自增导致编码过长。第三，编码中不放入供应商、检验结果等会变化的信息——批次编码应当一次生成、永不修改，可变属性放到事件表中。若企业已有 ERP 批次号，可采用“内部追溯码 + 外部映射表”的方式兼容，而不是推翻既有编码。

二、物料与成品的关联：多对多投料关系

一批成品通常由多种原料批次投料生产，一种原料批次也可能分散到多批成品中，因此物料与成品之间本质是多对多关系，必须通过“投料记录”这一关联实体表达，而不能在成品表里塞一个原料批次字段。投料记录至少包含：成品批次号、原料批次号、投料数量、计量单位、投料工位、投料时间、操作人。

这样建模后，正向追溯（成品→原料）和反向追溯（原料→受影响成品）都只是一次关联查询。例如某原料批次检出问题，按 原料批次号 查投料记录即可得到全部关联成品批次，再叠加发货事件即可圈定召回范围。需要注意计量单位统一：建议在投料记录中同时保存原始单位与折算后的基准单位（如千克），避免“袋/箱/桶”混算导致追溯数量对不上。

三、四类供应链事件的建模

生产、质检、仓储、物流事件虽然业务含义不同，但共享“批次号、事件类型、发生时间、地点、操作人、数量”等骨架字段。实践中推荐统一事件表 + 类型扩展表的混合结构：主事件表保存公共字段，各类型专有字段放入扩展表（如质检的检验项目与实测值、物流的承运商与签收人）。这样看板查询时间线时只需扫一张主表，而专有属性仍可精确检索。

几个容易踩坑的细节：质检事件要区分“检验结论”与“检验状态”，前者是合格/不合格，后者是待检/在检/已出报告，看板上二者不能混用；仓储事件要记录库位变更前后值，否则无法还原移动轨迹；物流事件应同时保存计划发运时间与实际发运时间，冷链场景还需挂接温度记录，温度超限本身可作为一条独立事件参与追溯。

四、时间序列与关系模型的选择

追溯数据天然具有双重属性：实体之间是关系（批次、投料、客户），事件则沿时间轴排列。因此不建议二选一，而是关系模型承载实体与关联，时间序列能力承载事件流。具体做法：批次、投料记录、客户等用关系表存储并建立外键与索引；事件表以 (batch_id, event_time) 为联合主键或聚簇索引，使“查某批次完整时间线”成为一次范围扫描。

当事件量达到千万级、且看板需要按小时聚合温湿度或产量趋势时，可将事件表按时间分区（如按月分区），或把高频传感器数据下沉到时序数据库，关系库仅保留事件摘要。判断依据是查询模式：以“单批次全链路回溯”为主，关系库加时间索引足够；以“跨批次时间窗口聚合”为主，才引入时序库，避免过早复杂化。

最后给出一份可直接对照的建表要点清单：批次表主键为批次号并建立唯一约束；投料记录表对 (成品批次号, 原料批次号, 投料时间) 建唯一约束防重复上报；事件表必须有 event_type 与 event_time 且 event_time 不允许为空；所有外键字段建立索引；数量字段统一保留基准单位与原始单位两列。按此模型落地后，看板上的“批次详情—时间线—关联成品—发货去向”四个视图都能由同一套表结构直接支撑，无需为每个视图单独造数。