追溯父子码关系怎么存?边表设计与递归反查SQL
本文讨论条码追溯里父子码关系的边表建模与递归反查写法。
MES报工接口幂等怎么做?唯一键、去重表与重试策略
MES 报工是车间最频繁的写入之一:扫码枪、工位终端、AGV 或 PDA 在工序完成时把完工数量、合格/不合格数、工时、设备/模具/批次等信息推给 MES。网络抖动、WIFI 漫游、扫码枪丢包、终端重启都会导致同一笔报工被重发。如果接口不是幂等的,重复提交会产生重复报工记录,产量虚高、在制品不准、追溯链条断裂,后续对账和成本核算都要手工清洗。幂等的含义在这里很具体:同一个报工请求无论提交几次,ME
追溯反查慢怎么优化?MySQL联合索引与冗余快照表的取舍
追溯系统做反向查询是常见场景:按成品序列号反查经历了哪些工序、哪些物料批次、谁在哪个工位操作。业务量上去后,反查页面经常要等十几秒甚至超时。很多人第一反应是把关联字段都加上索引,结果索引越建越多、写入越来越慢,反查也没实质变快。真正能把这类查询压到可接受范围的做法,通常是在 MySQL 联合索引与冗余快照表之间做取舍,而不是把两种手段混在一起。追溯反查慢,慢在两个地方。第一是查询路径长。典型的反查
MES与WMS库存同步:接口设计与对账表怎么做
MES与WMS之间的库存同步,可靠做法是"发件箱表+幂等收件表+日终对账表":业务数据与待发消息在同一个本地事务里落库,接收方按消息号去重,每天再按单据、数量、余额三个层次对一次账。实时接口负责快,对账负责准。本文给出接口清单、表结构、幂等写法、对账SQL、常见坑与验收项。
条码批次拆分合并怎么建模:父子批次关系表与递归查询
条码批次的拆分与合并,用“批次主表+父子关系边表+批次事务表”三张表建模比较稳妥:批次码一经生成不再修改,每一次拆分或合并都只新增关系边,再用递归公用表表达式向上追来源、向下追去向。本文给出表结构、数量守恒校验、MySQL 8 递归查询写法、环路与深度控制、常见坑与验收项。
MES追溯库分区表设计:按月分区、序列号索引与历史查询
MES追溯过程表按月做范围分区、按序列号单独建一张不分区的路由索引表,是兼顾写入、反查和归档的稳妥做法。按序列号查追溯时先查路由表拿到月份,再带着时间条件进分区表,才能触发分区裁剪;只按序列号直接查分区表,会把每个分区的本地索引都扫一遍。本文给出表结构、建表语句、分区维护脚本、常见坑与验收项。
WMS库存账怎么建模:库存余额表加库存流水表的双表设计
结论:WMS里库存数量不要直接改,正确做法是“每一次出入库只写一条流水,余额由流水累计得到”,同时保留一张余额表用于快速查询。这样账实不符时才能逐笔回溯,而不是对着一个被改过的数字猜原因。一、为什么不能直接改库存数量最常见的设计是一张库存表,入库就加、出库就减。问题在于:出现差异时没有历史,无法判断是重复扫码、漏扫、还是并发覆盖。双表设计把“结果”和“过程”分开:流水表只增不改,余额表是流水汇总后