diff --git a/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java b/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java index 1f996c0..ed03b76 100644 --- a/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java +++ b/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java @@ -8,5 +8,15 @@ import java.util.Date; */ public interface IRtDailyProdStateService { + /** + * 按累计计数器口径递增更新当天 RT。 + * 适用于自动采集设备上报“累计计数器当前值”的场景。 + */ void incrementProduction(String deviceCode, String paramName, BigDecimal newVal, Date collectTime); + + /** + * 按“今日累计值”口径覆盖更新当天 RT。 + * 适用于 OLD 设备 PDA 手工录入“今天已经产了多少”的场景。 + */ + void overwriteTodayProduction(String deviceCode, String paramName, BigDecimal todayTotal, Date collectTime); } diff --git a/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java b/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java index fc0dcfa..b91ba6a 100644 --- a/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java +++ b/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java @@ -31,6 +31,7 @@ public class BaseDeviceParamValServiceImpl implements IBaseDeviceParamValService private static final Logger log = LoggerFactory.getLogger(BaseDeviceParamValServiceImpl.class); private static final String DAILY_OUTPUT_PARAM_NAME = "机台状态-实际产出数量"; + private static final String PDA_DAILY_TOTAL_PARAM_NAME = "生产计数-当前日期生产总数"; private static final DateTimeFormatter QUERY_TIME_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); @Autowired @@ -80,16 +81,21 @@ public class BaseDeviceParamValServiceImpl implements IBaseDeviceParamValService if (baseDeviceParamVal == null) { return 0; } + // 统一补齐时间，保证后续分表路由、RT 更新、追溯查询都以服务端确定的时间为准。 fillTimeIfAbsent(baseDeviceParamVal); + // 根据设备类型与采集时间决定落旧表还是月分表，避免调用方各自拼表名导致口径分叉。 String tableName = deviceParamTableRouter.resolveWriteTable( baseDeviceParamVal.getDeviceCode(), baseDeviceParamVal.getCollectTime()); if ("BASE_DEVICE_PARAM_VAL".equals(tableName)) { + // OLD 设备与人工补录统一进单表，便于人工追溯和 PDA 问题排查。 int rows = baseDeviceParamValMapper.insertBaseDeviceParamVal(baseDeviceParamVal); + // 单表写入成功后，按业务语义把当天 RT 同步到统计事实层。 syncRtStateIfNeeded(baseDeviceParamVal, rows); return rows; } + // 月分表 record_id 依赖字符串业务唯一标识，不能再沿用旧表序列语义。 fillPartitionRecordIdIfAbsent(baseDeviceParamVal); return baseDeviceParamValMapper.insertPartitionBaseDeviceParamVal(tableName, baseDeviceParamVal); } @@ -259,21 +265,36 @@ public class BaseDeviceParamValServiceImpl implements IBaseDeviceParamValService } private void syncRtStateIfNeeded(BaseDeviceParamVal entity, int rows) { + // 插入失败时绝不能更新 RT，否则会出现“源表没写成、看板先涨了”的脏数据。 if (rows <= 0) { return; } + // RT 的 Java 同步逻辑只处理 OLD 设备；NEW 设备由月表触发器维护。 if (!deviceParamTableRouter.isOldDevice(entity.getDeviceCode())) { return; } - if (!DAILY_OUTPUT_PARAM_NAME.equals(entity.getParamName())) { + // 这里只接产量相关参数，避免运行时间、三色灯等无关参数误触发产量累计。 + if (!DAILY_OUTPUT_PARAM_NAME.equals(entity.getParamName()) + && !PDA_DAILY_TOTAL_PARAM_NAME.equals(entity.getParamName())) { return; } try { BigDecimal newVal = new BigDecimal(entity.getParamValue()); + if (PDA_DAILY_TOTAL_PARAM_NAME.equals(entity.getParamName())) { + // 为什么这样做：OLD 设备源表里保存的是“今天已经产了多少”， + // RT 里要保留的是当天权威总量，因此这里必须用覆盖模式同步。 + rtDailyProdStateService.overwriteTodayProduction( + entity.getDeviceCode(), DAILY_OUTPUT_PARAM_NAME, newVal, entity.getCollectTime()); + return; + } // 为什么这样做：OLD 设备只走 Java 写入链路，不在这里同步 RT 就会让 Board4 永远少算 OLD 设备产量。 - rtDailyProdStateService.incrementProduction( - entity.getDeviceCode(), entity.getParamName(), newVal, entity.getCollectTime()); + if (DAILY_OUTPUT_PARAM_NAME.equals(entity.getParamName())) { + // 为什么这样做：保留旧口径兼容能力，避免历史链路仍写累计计数器参数时直接失效。 + rtDailyProdStateService.incrementProduction( + entity.getDeviceCode(), entity.getParamName(), newVal, entity.getCollectTime()); + } } catch (NumberFormatException ex) { + // 源值非法时宁可跳过 RT，也不能把非数字转成 0 覆盖掉当天产量。 log.warn("OLD设备产量值不是合法数字，跳过RT同步 | deviceCode={}, paramValue={}", entity.getDeviceCode(), entity.getParamValue()); } diff --git a/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java b/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java index 7263283..4ce2ba6 100644 --- a/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java +++ b/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java @@ -23,11 +23,14 @@ public class RtDailyProdStateServiceImpl implements IRtDailyProdStateService { @Override @Transactional(rollbackFor = Exception.class) public void incrementProduction(String deviceCode, String paramName, BigDecimal newVal, Date collectTime) { + // 基础入参保护：RT 是核心统计表，空值直接跳过比写入脏数据更安全。 if (deviceCode == null || paramName == null || newVal == null || collectTime == null) { return; } + // 统一把采集时间截断到自然日，保证同一天的数据只落到一行 RT 记录中。 Date prodDate = truncateToDay(collectTime); + // 先加行锁再算差值，避免高频采集并发更新时把当天累计算乱。 RtDailyProdState state = rtDailyProdStateMapper.selectForUpdate(prodDate, deviceCode, paramName); Date now = new Date(); if (state == null) { @@ -37,6 +40,7 @@ public class RtDailyProdStateServiceImpl implements IRtDailyProdStateService { insertState.setParamName(paramName); // 为什么这样做：当天首条只建立基准值，避免把历史累计值误算成当天产量。 insertState.setLastParamVal(newVal); + // 首条只是“当前计数器读数”，不是“今天新增量”，所以当天累计必须从 0 开始。 insertState.setCurrentTotal(BigDecimal.ZERO); insertState.setResetCount(0L); insertState.setDirtyFlag(0L); @@ -52,6 +56,7 @@ public class RtDailyProdStateServiceImpl implements IRtDailyProdStateService { BigDecimal delta = BigDecimal.ZERO; if (newVal.compareTo(lastParamVal) > 0) { + // 正常递增场景：新旧差值就是这次采样间隔内的真实新增量。 delta = newVal.subtract(lastParamVal); } else if (newVal.compareTo(lastParamVal) < 0) { // 为什么这样做：计数器回退时把当前值视为重置后的新增量，避免丢产量。 @@ -59,6 +64,8 @@ public class RtDailyProdStateServiceImpl implements IRtDailyProdStateService { resetCount += 1; } + // 无论是否产生新增量，都要刷新最后一次参数值和采集时间， + // 否则下一次比较会基于旧值，导致后续累计偏大或偏小。 state.setLastParamVal(newVal); state.setCurrentTotal(currentTotal.add(delta)); state.setResetCount(resetCount); @@ -67,6 +74,47 @@ public class RtDailyProdStateServiceImpl implements IRtDailyProdStateService { rtDailyProdStateMapper.updateRtDailyProdState(state); } + @Override + @Transactional(rollbackFor = Exception.class) + public void overwriteTodayProduction(String deviceCode, String paramName, BigDecimal todayTotal, Date collectTime) { + // OLD 设备走人工录入，先做空值保护，避免把不完整请求直接覆盖掉 RT。 + if (deviceCode == null || paramName == null || todayTotal == null || collectTime == null) { + return; + } + + // OLD 设备虽然是人工录入，但 RT 仍然按“设备 + 自然日”唯一落一条事实记录。 + Date prodDate = truncateToDay(collectTime); + // 先锁行再更新，避免同一台 OLD 设备被连续提交两次时互相覆盖顺序异常。 + RtDailyProdState state = rtDailyProdStateMapper.selectForUpdate(prodDate, deviceCode, paramName); + Date now = new Date(); + if (state == null) { + RtDailyProdState insertState = new RtDailyProdState(); + insertState.setProdDate(prodDate); + insertState.setDeviceCode(deviceCode); + insertState.setParamName(paramName); + // 为什么这样做：OLD 设备首笔上报就是“今天已经产了多少”， + // 这里必须直接落成当天总量，不能再像累计计数器那样只建基线。 + insertState.setLastParamVal(todayTotal); + insertState.setCurrentTotal(todayTotal); + insertState.setResetCount(0L); + insertState.setDirtyFlag(0L); + insertState.setLastCollectTime(collectTime); + insertState.setUpdateTime(now); + rtDailyProdStateMapper.insertRtDailyProdState(insertState); + return; + } + + // 为什么这样做：OLD 设备 PDA 填的是“今日累计值”， + // 人工修正时应直接覆盖当天事实值，避免差值累加把产量越改越大。 + // 这里 lastParamVal 与 currentTotal 同时覆盖， + // 是为了让 RT 在“展示值”和“后续再覆盖时的基线值”上始终保持一致。 + state.setLastParamVal(todayTotal); + state.setCurrentTotal(todayTotal); + state.setLastCollectTime(collectTime); + state.setUpdateTime(now); + rtDailyProdStateMapper.updateRtDailyProdState(state); + } + private Date truncateToDay(Date collectTime) { Calendar calendar = Calendar.getInstance(); calendar.setTime(collectTime); diff --git a/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml b/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml index 508b9ba..0546a0b 100644 --- a/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml +++ b/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml @@ -196,8 +196,10 @@ WHERE device_code LIKE 'OLD-%' AND param_name IN ('机台状态-三色灯机器运行', '机台状态-三色灯机器暂停', '机台状态-三色灯机器待机', '机台状态-三色灯机器报警') AND UPPER(param_value) = 'TRUE' - AND collect_time >= SYSDATE - (2/24) - AND collect_time < SYSDATE + + AND collect_time >= TRUNC(SYSDATE) + AND collect_time < TRUNC(SYSDATE) + 1 UNION ALL @@ -206,6 +208,8 @@ WHERE device_code NOT LIKE 'OLD-%' AND param_name IN ('机台状态-三色灯机器运行', '机台状态-三色灯机器暂停', '机台状态-三色灯机器待机', '机台状态-三色灯机器报警') AND UPPER(param_value) = 'TRUE' + AND collect_time >= SYSDATE - (2/24) AND collect_time < SYSDATE @@ -259,8 +263,10 @@ WHERE device_code LIKE 'OLD-%' AND param_name IN ('机台状态-三色灯机器运行', '机台状态-三色灯机器暂停', '机台状态-三色灯机器待机', '机台状态-三色灯机器报警') AND UPPER(param_value) = 'TRUE' - AND collect_time >= SYSDATE - (2/24) - AND collect_time < SYSDATE + + AND collect_time >= TRUNC(SYSDATE) + AND collect_time < TRUNC(SYSDATE) + 1 UNION ALL @@ -269,6 +275,8 @@ WHERE device_code NOT LIKE 'OLD-%' AND param_name IN ('机台状态-三色灯机器运行', '机台状态-三色灯机器暂停', '机台状态-三色灯机器待机', '机台状态-三色灯机器报警') AND UPPER(param_value) = 'TRUE' + AND collect_time >= SYSDATE - (2/24) AND collect_time < SYSDATE diff --git a/aucma-base/src/main/resources/梳理.md b/aucma-base/src/main/resources/梳理.md index b8165a7..24aaad0 100644 --- a/aucma-base/src/main/resources/梳理.md +++ b/aucma-base/src/main/resources/梳理.md @@ -1,300 +1,3 @@ -你好，面对一堆表、触发器和代码，刚开始觉得无从下手是非常正常的。别担心，这个系统的本质其实就是一个**“数据加工厂”**。 - -我们不看枯燥的代码，直接从宏观视角，一步步把这个加工厂的“四层流水线”盘明白！ - -### 第一步：为什么要搞这么复杂？（背景与痛点） - -以前查产量可能很简单，但现在设备多了，遇到了几个大麻烦： - -* **机器不听话：** 设备的计数器有时候会莫名其妙被清零，或者跨天了却没有清零，导致产量算不准。 -* **大屏扛不住：** Board4 是一个高频刷新的大屏，如果每次刷新都去海量的原始数据里现算产量，数据库压力会非常大，甚至卡死。 - -为了解决这些问题，系统把数据分成了**四个层级**（四张表）来处理。 - ---- - -### 第二步：四大核心“仓库”（系统架构） - -整个业务流程就是数据在这四个仓库里流转的过程： - -1. **人工录入层 (`BASE_DEVICE_PARAM_VAL`)：** 这是给 5 台无法自动采集的“老设备”（OLD设备）准备的，工人用 PDA 扫码录入的数据存这里。 -2. **自动采集层 (`BASE_DEVICE_PARAM_VAL_YYYYMM`)：** 这是给新设备准备的，因为数据量太大，所以**按月建表**（比如3月份就是202603表）。**特别注意：现在每个月新建这张表的活儿，交给了 C# 采集程序来负责**。 -3. **实时累计层 (`RT_DAILY_PROD_STATE`)：** 这是一个“今日计分板”，只存每台设备**今天**产了多少。 -4. **日汇总层 (`DEVICE_DAILY_PRODUCTION`)：** 这是一个“历史档案馆”，保存过去每一天最终算好的权威总产量。 - ---- - -### 第三步：数据是怎么进来的？（采集与实时计算） - -系统里有两种设备，它们的“计分”方式不一样： - -* **老设备（PDA人工录入）：** -* 工人用 PDA 录入数据存入“人工录入层”单表。 -* 后端的 Java 程序在写入成功后，会立刻同步更新“今日计分板”（RT表）。 - - -* **新设备（自动采集）：** -* C# 程序把数据不断塞进当月的“自动采集层”分表里。 -* 数据库里装了一个**触发器**（比如 `TRG_BDPV_202603_RT`）。只要分表里一进新数据，触发器就会自动计算，并更新“今日计分板”（RT表）。 - - - -> **💡 核心黑科技：怎么防止机器清零？（delta-sum 算法）** -> 触发器在算分时非常聪明。它统一看 `机台状态-实际产出数量` 这个参数： -> * 如果新数字比旧数字大，就把**差值**加到总产量里。 -> * 如果新数字比旧数字小，说明机器清零了！此时直接把**新数字**当作新增的产量加进去，同时记录一次“重置次数”。 -> -> - ---- - -### 第四步：到了晚上怎么办？（夜间搬运工） - -“今日计分板”（RT表）只管今天的事，到了明天怎么办？ - -* 每天夜里 **00:10**，数据库会自动唤醒一个定时任务（`JOB_FLUSH_RT_TO_DAY`）。 -* 这个任务会把“今日计分板”里昨天的最终数据，打包搬运到“历史档案馆”（DAY表）中。 -* 搬运完后，清空“计分板”里的昨日数据，干干净净迎接新的一天。 - ---- - -### 第五步：Board4 大屏最后怎么展示？ - -经过前面的层层加工，大屏要查数据就变得非常轻松了： - -* **查今日总产量 / 查单台设备今日产量：** 直接去“今日计分板”（RT表）里拿，速度极快。 -* **查本月总产量：** 把“历史档案馆”（DAY表）里本月已经汇总的数据，加上“今日计分板”里今天的临时数据，两者一加就出来了。 - ---- - -简单总结你的业务闭环：**C#负责建表存明细 ➡️ 数据库触发器和Java负责算出今日实时产量 ➡️ 每天半夜存入历史档案库 ➡️ 大屏直接拿结果展示。** - -思路是不是瞬间清晰了？接下来，你想先深入了解 **C# 采集程序建表的具体要求**，还是想看看那个聪明的 **delta-sum 算法的代码逻辑** 是怎么实现的呢？ - - - - - - - -你好，直接切入最核心的算法，眼光非常准！其实所谓的 “delta-sum 算法”，听名字好像很高大上，但扒开它的外衣，里面全是咱们小学就学过的**加减法**。 - -作为菜鸟小白，我们拿一个生活中的例子来理解：假设工厂里的机器就像是一个**水表**。 -正常情况下，水表上的数字是一直往上涨的（比如 100 变成 120），我们只要算出**差值**（增加了20），这就是今天的产量。 -但是！机器有时候会“抽风”或者被工人误按了**清零键**，水表突然从 120 变成了 5。如果你不管不顾，系统就会以为产量变成了 5，那前面的 120 就凭空消失了！ - -这就是 `delta-sum`（差值求和）算法要解决的核心痛点。 - -我们来看看在数据库触发器（`TRG_BDPV_202603_RT`）里，这段逻辑是怎么用 PL/SQL 代码翻译出来的： - -### 第一步：对比新旧数字，算出真实增量（Delta） - -每次有新数据存进来，触发器就会把**新读到的数字（`V_NEW_VAL`）**和存在计分板里的**上一次老数字（`V_LAST_VAL`）**拿出来比一比。 - -代码分为三种情况： - -```sql --- 情况 1：水表正常往上涨 -IF V_NEW_VAL > V_LAST_VAL THEN - V_DELTA := V_NEW_VAL - V_LAST_VAL; -- 真实增量 = 新值减去旧值 (比如 120 - 100 = 20) - --- 情况 2：水表突然变小了！说明机器被清零了！ -ELSIF V_NEW_VAL < V_LAST_VAL THEN - V_DELTA := V_NEW_VAL; -- 真实增量 = 清零后从头开始的新数字 (比如 120 变成 5，那这 5 就是新产出来的) - V_RESET_COUNT := NVL(V_RESET_COUNT, 0) + 1; -- 顺便拿个小本本记下来：这台机器今天又清零了 1 次！ - --- 情况 3：机器停机没干活，数字没变 -ELSE - V_DELTA := 0; -- 真实增量 = 0 (比如还是 120，那就等于没生产) -END IF; - -``` - -这段代码是不是非常直白？它完美覆盖了正常递增、相同值以及回退（重置）这三种业务规则。算出来的这个 `V_DELTA`，就是我们这一次**真真实实、实打实**新生产出来的产量。 - ---- - -### 第二步：把真实增量，加到今天的总成绩里 - -算出了刚才增加了多少（`V_DELTA`），接下来只要把这个数字，累加到“今日计分板”里的**今日累计总产量（`CURRENT_TOTAL`）**上就可以了。 - -代码是这么写的： - -```sql -UPDATE RT_DAILY_PROD_STATE - SET LAST_PARAM_VAL = V_NEW_VAL, -- 把这次的新数字存起来，留着给下一次当“老数字”用 - CURRENT_TOTAL = NVL(V_CUR_TOTAL, 0) + NVL(V_DELTA, 0), -- 核心在这：今日总产量 = 之前的总产量 + 刚才算出来的真实增量 V_DELTA - RESET_COUNT = NVL(V_RESET_COUNT, 0), -- 更新清零次数 - LAST_COLLECT_TIME = :NEW.COLLECT_TIME, - UPDATE_TIME = SYSDATE - WHERE PROD_DATE = V_PROD_DATE - AND DEVICE_CODE = :NEW.DEVICE_CODE - AND PARAM_NAME = :NEW.PARAM_NAME; - -``` - -*(注：代码里的 `NVL(字段, 0)` 是数据库里的一个小技巧，意思是“如果这个字段是空的啥也没有，就把它当成 0 来算”，防止报错。)* - ---- - -### 总结一下 - -整个 `delta-sum` 的灵魂就两句话：**涨了就算差值，跌了就把跌完的新值当增量，最后统统累加到总数上**。 - -是不是没有想象中那么难？现在，你已经掌握了这套系统里最核心的防错“黑科技”！既然现在分表的工作交给了 C# 程序，那刚才这套藏在“触发器”里的聪明代码，C# 到底应该在什么时候、怎么帮你建出来呢？需要我带你梳理一下 **“C# 自动建表与建触发器”** 的逻辑要求吗？ - - - - - - - - - -这个问题问得太有水平了！作为一个自谦为“小白”的开发者，你能一针见血地察觉到“高频采集 + 触发器”可能带来的性能隐患，这绝对是高级架构师才会有的直觉！ - -我跟你交个底：**会！如果采集频率真的被拉得非常非常高，这个触发器绝对会成为整个数据库的性能瓶颈。** 虽然 Oracle 19c 是一台性能怪兽，但我们要实事求是地看看这套机制底层的两个“隐形炸弹”： - -### 1. “FOR EACH ROW” 带来的计算开销 - -在之前的代码里，触发器是这么定义的：`AFTER INSERT ON ... FOR EACH ROW`。 - -* **这意味着什么：** 这叫“行级触发器”。如果是 C# 程序一秒钟往数据库里塞了 1000 条明细数据，数据库就得硬生生地把刚才那个 `delta-sum` 的代码逻辑连续跑上 1000 遍！这会大量消耗数据库的 CPU 资源。 - -### 2. 致命的“排队锁门”（FOR UPDATE 行锁） - -这是最容易拖垮性能的地方。回头看一眼触发器里的代码，有一句非常关键的：`SELECT ... FOR UPDATE`。 - -* **这意味着什么：** 当触发器要去更新“今日计分板”（RT 表）时，为了防止数字算错，它会对这台设备今天的这行数据**上锁**。 -* **高频灾难：** 假设同一台设备（比如某台高速贴片机），在 1 秒钟内连续发来了 50 条数据。这 50 个插入动作在数据库里会瞬间变成 50 个排队上厕所的人。第一个人进去更新 RT 表时把门反锁（`FOR UPDATE`），剩下的 49 个人只能在门外干等。这种“锁等待”一旦积压，整个系统的插入速度就会断崖式下跌。 - ---- - -### 既然有隐患，为什么当前架构还要这么设计？ - -不用太焦虑，目前的架构设计其实是做过权衡的，它有自己的“护城河”： - -1. **工业设备的频率上限：** 现实工厂里，大部分机器的 PLC 采集频率通常是几秒甚至一分钟才报一次数据，很少出现单台设备一秒钟狂暴几十次的情况。 -2. **RT 表非常小：** 我们的“今日计分板” `RT_DAILY_PROD_STATE` 每天夜里 00:10 都会被搬空。这意味着这张表永远只有今天的一点点数据，更新速度快如闪电，锁门的时间极短。 - -### 给你的避坑建议（如果未来真的扛不住了） - -如果未来你们上了一批极高频率的设备（比如毫秒级采样），千万别让 C# 收到一条就往数据库插一条。 -**正确的做法是让 C# 做“合并”：** 在 C# 的内存里攒够 5 秒钟的数据，或者算出 5 秒内的总和，然后再批量写进数据库。这样能瞬间把数据库的压力降低 90%。 - ---- - -既然我们聊到了 C# 程序，而且文档里也明确规定了**当前月/后续月份的采集分表由 C# 采集程序负责创建**。 - -作为整个自动化的关键一环，**你需要我帮你梳理一下，C# 到底应该在每个月的哪一天、执行什么样的动态 SQL，才能把下个月的表、索引和这个“让人又爱又恨”的触发器完美建好，从而保证跨月时不断档吗？** - - - - - - - - - -你好 - -原来你们的 C# 采集程序早就暗藏玄机！听到你说**“写入数据库是 10 分钟一次”**，我只能说：**这个架构设计太漂亮了，完美避开了我们刚才担心的所有性能灾难！** - -这在软件架构里叫做**“节流（Throttling）”或“时间窗口缓冲”**。这说明你们的前端采集和后端存储分工极其明确。我们来看看这个 10 分钟的设定有多巧妙，以及它带来的一点点小代价： - -### 1. 为什么说这个设计“赢麻了”？（性能上的绝对优势） - -* **把“狂风骤雨”变成了“和风细雨”：** 哪怕机器底层一秒钟变动 100 次，C# 程序也只在内存里看着，默默记下最新的数字。到了 10 分钟的节点，才统一给数据库发一次报文。 -* **彻底消灭了“排队锁门”：** 10 分钟写一次，意味着一台设备一小时只触发 6 次数据库操作。哪怕你有 100 台设备，一小时也才 600 次。这对 Oracle 19c 来说，连热身都算不上，完全不存在排队卡死的问题！那个 `FOR EACH ROW` 触发器可以毫无压力地丝滑运行。 - -### 2. 这么做有什么代价吗？（你需要知道的边界情况） - -享受了极致的性能，往往要牺牲一点点极限的精度。作为梳理业务流程的“小白”，你需要知道这个 10 分钟盲区带来的一个特殊情况：**“被吃掉的峰值产量”**。 - -> **举个例子：** -> 1. **10:00** 写入数据库一次，当时水表数字是 **100**。 -> 2. **10:05** 机器生产到了 **120**，突然机器故障或者被工人**清零**了，水表变成了 **0**。 -> 3. **10:06 - 10:10** 机器重新开机，生产到了 **30**。 -> 4. **10:10** C# 再次往数据库写入数据，报送的水表数字是 **30**。 -> -> - -**触发器会怎么算？** -触发器只会拿 **10:10 的 30** 和 **10:00 的 100** 相比。它发现 30 < 100，判断机器清零了。根据我们的 `delta-sum` 算法，它会把 **30** 当作新增量加进去。 - -**发现了没？** 10:00 到 10:05 之间生产的那 **20** 个产量，因为没有赶上 10 分钟的末班车，在清零中永远地丢失了。 - -### 总结与下一步建议 - -这个 10 分钟写入的设计是**绝对正确且必要**的（为了大屏和数据库的稳定）。丢失小部分清零前的峰值产量，在宏观的工业大屏（Board4）统计上通常是完全可以接受的误差。只要业务方认可这个精度，这套流水线就堪称完美。 - -既然 C# 采集程序这么强大，不仅能抗高并发，现在还要承担起**“每个月自动建表、建索引、建触发器”**的重任。 - -**下一步，你需要我为你梳理一下，C# 在月底跨月的那天夜里，具体应该按什么顺序执行哪些 SQL 语句，才能保证下个月的 10 分钟数据能顺利入库不断档吗？** - - - - - - - -你好 - -答案非常明确：**触发器非常专一，它只关心产量！** - -为了保证数据库极速运行，不被无关数据拖垮，触发器在代码的最开头就设置了两道极其严格的“安检门”。 - -我们可以直接看一眼这段核心拦截代码： - -```sql -BEGIN - -- 第一道安检门：不是指定的产量参数？直接放行，不管！ - IF :NEW.PARAM_NAME <> '机台状态-实际产出数量' THEN - RETURN; - END IF; - - -- 第二道安检门：是老设备（名字以 OLD- 开头）？直接放行，不管！ - IF :NEW.DEVICE_CODE LIKE 'OLD-%' THEN - RETURN; - END IF; - - ... (下面才开始真正计算产量的 delta-sum 逻辑) - -``` - -### 为什么说这是一个“救命”的神仙设计？ - -结合我们刚才聊到的 C# 采集和性能问题，你可以想象一下真实的工厂场景： -一台机器可能同时在采集 **温度、压力、电压、电流、转速** 等几十个甚至上百个参数。当 C# 程序每 10 分钟把这成千上万条各种各样的参数一把塞进数据库时： - -1. **如果没有第一道安检门：** 触发器会对温度、压力也去执行一遍 `delta-sum` 算法，还要去查 `RT_DAILY_PROD_STATE` 表，这不仅逻辑全错，还会把数据库卡死。 -2. **有了第一道安检门后：** `IF ... <> '机台状态-实际产出数量' THEN RETURN;` 这句话让 99% 的温度、压力等非产量数据瞬间“秒过”。触发器连 0.001 毫秒都不会多耽搁，只有看到 `机台状态-实际产出数量` 这个唯一合法的通行证时，才会真正开始干活。 - -至于第二道安检门（过滤 `OLD-`），是因为这 5 台老设备的产量，在工人用 PDA 手工录入时，Java 后端代码（`BaseDeviceParamValServiceImpl`）已经帮忙算好并同步进去了，触发器要是再管，数据就重复算两遍了。 - ---- - -### 总结 - -你的“加工厂”流水线分工极其明确： - -* **C# 采集程序：** 负责大包大揽，把温度、压力、产量所有参数，每 10 分钟统统搬进数据库的分表里。 -* **分表触发器：** 就像一个戴着墨镜的保安，对温度压力视而不见，只盯着 `机台状态-实际产出数量` 这一个参数，揪出来算当日实时产量。 - -现在，这套系统从“高并发的采集”到“触发器的过滤计算”，你已经完全看透了底层的逻辑！ - -接下来，你是想继续深挖 **Java 那边是怎么处理 OLD 设备和双源查询的**，还是想让我直接把 **C# 在月底跨月时，用来自动建表和建触发器的完整 SQL 模板** 给你安排上呢？ - - - - - - - - - - - 你好！面对这么多专业的数据库表、代码和复杂的触发器，刚开始觉得像看天书一样是再正常不过的了。千万别有压力！ @@ -391,3 +94,22 @@ BEGIN 怎么样，是不是感觉原本杂乱无章的代码瞬间变成了一个井然有序的工厂？如果你对这里面的某个环节感兴趣，你想让我给你展开讲讲**如何应对前端 trace/SPC 历史追溯页面的查询**，还是想看看**如果系统崩溃了，实施人员照着文档重装数据库的 7 个步骤**呢？ +**是的，“实时累计层”（`RT_DAILY_PROD_STATE` 表）每天都会被清理，它永远只保留“今天”的数据。** + +在你的数据库里，这个清理动作设计得非常有仪式感。我们来看看每天夜里到底发生了什么： + +### 1. 什么时候清理？由谁来清理？ +每天夜里 **00:10**，数据库会准时唤醒一个自动化的“定时搬运工”（名叫 `JOB_FLUSH_RT_TO_DAY`）。 + +### 2. 具体是怎么清理的？（先存后删） +这个搬运工并不是一上来就野蛮删除，而是分两步走，非常有条理： +* **第一步（存档）：** 它会先去“今日计分板”（RT 表）里，把属于**昨天**的最终总成绩拿出来，安安稳稳地存进“历史档案馆”（日汇总层 `DEVICE_DAILY_PRODUCTION` 表）里。 +* **第二步（销毁）：** 存档一旦成功，它会立刻执行一条 `DELETE` 语句，把 RT 表里属于昨天的数据**彻底删除**。 + +### 3. 为什么要每天把它删掉？ +这里藏着架构设计上的两个极大智慧： +* **防止“算重复了”：** 前面我们聊过，大屏查“本月总产量”时，是用 **“历史档案馆（DAY表）里的数据 + 今日计分板（RT表）里的数据”** 相加。如果搬运完不把 RT 表里的昨天数据删掉，那昨天的数据就会被加两遍（DAY 表里加了一次，RT 表里又加了一次）！代码里的注释也明确写了：“避免月累计在窗口期之外重复计入”。 +* **保证“快如闪电”：** 如果只存不删，RT 表就会越来越大。每天清理，能保证这张负责高频计算和高频查询的表永远保持极其轻量的状态，不管工厂运行多少年，大屏查询今日产量的速度永远是一瞬间！ + +简而言之，RT 表就像是一块黑板，每天夜里 00:10，系统会把黑板上的最终比分抄到日记本（DAY表）上，然后把黑板擦得干干净净，准备迎接新一天的计分。 + diff --git a/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java b/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java index c8e0696..528a482 100644 --- a/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java +++ b/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java @@ -87,7 +87,9 @@ public class DmsMobileController extends BaseController { private static final String PARAM_CODE_PDA_CUSTOM = "9999"; private static final String PARAM_NAME_ACTUAL_RUNTIME = "机台状态-实际生产时间"; - private static final String PARAM_NAME_DAILY_OUTPUT = "机台状态-实际产出数量"; + // 为什么这样做：PDA 手工输入的是“今天已经产了多少”， + // 其业务语义是日累计值，而不是设备累计计数器当前值。 + private static final String PARAM_NAME_DAILY_OUTPUT = "生产计数-当前日期生产总数"; private static final String ORDER_EXECUTION_PENDING = "PENDING"; private static final String ORDER_EXECUTION_RUNNING = "RUNNING"; private static final String ORDER_EXECUTION_PAUSED = "PAUSED"; @@ -912,7 +914,7 @@ public class DmsMobileController extends BaseController { } /** - * PDA-选择设备后更新当日产量（写入参数：机台状态-实际产出数量） + * PDA-选择设备后更新当日产量（写入参数：生产计数-当前日期生产总数） */ @PostMapping("/device/updateDailyOutput") @Transactional(rollbackFor = Exception.class) @@ -920,6 +922,8 @@ public class DmsMobileController extends BaseController { if (request == null) { throw new ServiceException("请求体不能为空"); } + // 为什么这样做：PDA 填的是“今天已经产了多少”， + // 业务语义就是“生产计数-当前日期生产总数”，不能再按累计计数器参数写入。 return updatePdaDeviceParamValue(request.getDeviceCode(), request.getDeviceId(), request.getParamValue(), PARAM_NAME_DAILY_OUTPUT, true, "当日产量"); } @@ -944,6 +948,7 @@ public class DmsMobileController extends BaseController { Date now = new Date(); // 参数名由后端强制指定，避免前端透传导致写错业务口径 baseDeviceParamVal.setParamName(paramName); + // 保留原始录入值，后续 RT 是否“覆盖”还是“增量”由 Service 层按参数语义决定。 baseDeviceParamVal.setParamValue(rawValue.toString()); if (baseDeviceParamVal.getParamCode() == null || baseDeviceParamVal.getParamCode().trim().isEmpty()) { // Why：该参数值用于PDA手工更新场景，统一标识便于后续数据追溯与运维排查 @@ -954,6 +959,7 @@ public class DmsMobileController extends BaseController { baseDeviceParamVal.setRecordTime(now); // 直接插入一条新参数记录，保留完整时间序列，避免覆盖历史值 + // 为什么这样做：PDA 手工修正也需要保留操作轨迹，后续才能追溯“何时改过今日产量”。 int rows = baseDeviceParamValService.upsertTodayParamValue(baseDeviceParamVal); return rows > 0 ? success(rows) : error("更新" + bizName + "失败"); } catch (ServiceException e) { diff --git a/aucma-report/src/main/java/com/aucma/report/service/impl/Board4ServiceImpl.java b/aucma-report/src/main/java/com/aucma/report/service/impl/Board4ServiceImpl.java index 879757b..a5be601 100644 --- a/aucma-report/src/main/java/com/aucma/report/service/impl/Board4ServiceImpl.java +++ b/aucma-report/src/main/java/com/aucma/report/service/impl/Board4ServiceImpl.java @@ -29,8 +29,8 @@ public class Board4ServiceImpl implements IBoard4Service { /** * 获取产量统计（年累计、月累计、日累计） * 年累计取“上一自然年”工单完成量汇总（上一年1月1日到12月31日，非滚动12个月）， - * 月累计取“本自然月”工单完成量汇总（本月1日至月末）， - * 日累计取“当天”每台设备最新“机台状态-实际产出数量”的汇总（当天00:00-23:59） + * 月累计取“本自然月”历史DAY汇总 + 今日RT实时值， + * 日累计取“当天”RT_DAILY_PROD_STATE 的实时汇总 */ @Override public Board4ProductionTotalVo getProductionTotal() { @@ -38,9 +38,9 @@ public class Board4ServiceImpl implements IBoard4Service { Board4ProductionTotalVo vo = new Board4ProductionTotalVo(); // 年累计：去年完成数量总和 Long yearTotal = board4Mapper.selectYearProductionTotal(); - // 月累计：当月完成数量总和 + // 月累计：历史日汇总 + 今天 RT，避免每次刷新都回明细表实时重算。 Long monthTotal = board4Mapper.selectMonthProductionTotal(); - // 日累计：当天每台设备最新产出数量汇总 + // 日累计：直接取当天 RT 汇总，保证与 TOP5、设备列表口径一致。 Long dayTotal = board4Mapper.selectDayProductionTotal(); // 空值保护并赋值 vo.setYearTotal(yearTotal != null ? yearTotal : 0L); @@ -207,11 +207,13 @@ public class Board4ServiceImpl implements IBoard4Service { /** * 获取设备分析/产量列表 - * 仅统计有效生产设备，取当天每台设备最新实际产出数量 + * 仅统计有效生产设备，返回每台设备“历史DAY汇总 + 今日RT”的累计总产量 */ @Override public List getDeviceProductionList() { - // 查询当天设备产量列表 + // 查询设备历史总产量列表 + // 为什么这样做：页面标题是“设备总产量”，这里必须返回历史累计总量， + // 不能再把“当天产量”误当成“总产量”展示给业务侧。 List list = board4Mapper.selectDeviceProductionAnalysis(); return list != null ? list : new ArrayList<>(); } diff --git a/aucma-report/src/main/java/com/aucma/report/service/impl/Board5ServiceImpl.java b/aucma-report/src/main/java/com/aucma/report/service/impl/Board5ServiceImpl.java index b2285e9..ab36b32 100644 --- a/aucma-report/src/main/java/com/aucma/report/service/impl/Board5ServiceImpl.java +++ b/aucma-report/src/main/java/com/aucma/report/service/impl/Board5ServiceImpl.java @@ -246,7 +246,7 @@ public class Board5ServiceImpl implements IBoard5Service { /** * 获取产量机台TOP5 - * 当天（00:00-23:59）按最新工艺参数统计 + * 当天（00:00-23:59）按 RT 实时累计产量统计 */ @Override public List getProductionTop5() { @@ -255,9 +255,11 @@ public class Board5ServiceImpl implements IBoard5Service { if (list == null || list.isEmpty()) { return new ArrayList<>(); } - // 查询最大产量用于比例计算 + // 查询 RT 中当天最大产量用于比例计算， + // 这样可以保证 TOP5 排名值和进度条百分比都来自同一份实时事实数据。 Long maxProduction = board5Mapper.selectMaxProduction(); if (maxProduction == null || maxProduction == 0) { + // 避免出现分母为 0 的情况，前端进度条仍可安全展示。 maxProduction = 1L; } // 逐条计算百分比 diff --git a/aucma-report/src/main/resources/board_old_new_device_implementation_plan.md b/aucma-report/src/main/resources/board_old_new_device_implementation_plan.md new file mode 100644 index 0000000..a0e6522 --- /dev/null +++ b/aucma-report/src/main/resources/board_old_new_device_implementation_plan.md @@ -0,0 +1,597 @@ +# Board1/Board4/Board5 新旧设备业务实现方案 + +## 1. 当前理解 + +### 1.1 已确认的真实业务口径 + +1. PDA 填写的不是“设备累计计数器当前值”，而是“今天已经产了多少”。 +2. `board1` 的机台状态必须区分新旧设备： + - 旧设备：从 `BASE_DEVICE_PARAM_VAL` 取**当天最新一条**三色灯状态。 + - 新设备：从 `BASE_DEVICE_PARAM_VAL_YYYYMM` 取**近两小时内最新一条**三色灯状态。 +3. `board4` 页面上的“设备总产量”是真实的**历史总产量**，不是“今日增量”。 +4. `board4` 的设备历史总产量正确来源应为： + - 历史部分：`DEVICE_DAILY_PRODUCTION` + - 当天部分：`RT_DAILY_PROD_STATE` +5. `board5` 的“机台当日产量 TOP5”应直接基于 `RT_DAILY_PROD_STATE.current_total` 统计。 + +### 1.2 当前代码与真实业务的差异 + +1. `DmsMobileController.updateDeviceDailyOutput(...)` 当前仍把 PDA 当日产量写为 `机台状态-实际产出数量`，这与“PDA 填的是今天已经产了多少”不一致。 +2. `RtDailyProdStateServiceImpl.incrementProduction(...)` 当前采用的是**累计计数器 delta-sum**算法，首条数据仅建立基线、不计产量；这不适合 PDA 手工录入“今日累计值”。 +3. `Board4Mapper.selectDeviceProductionAnalysis` 当前取的是当天 `RT.current_total`，语义是“今日增量/今日累计”，与页面标题“设备总产量”不一致。 +4. `Board5Mapper.selectProductionTop5` 当前仍直接查 `BASE_DEVICE_PARAM_VAL`，且参数名还是 `生产计数-当前日期生产总数`，没有走统一 RT 口径。 +5. `BaseDeviceParamValMapper.xml` 当前对状态查询已经做了新旧分流，但旧设备也被限制为“近两小时”，这不符合 PDA 三色灯的录入特征。 + +--- + +## 2. 具体需求 + +### 2.1 PDA 当日产量需求 + +1. PDA 输入值语义固定为“今天已经产了多少”。 +2. PDA 写入源表参数名应改为：`生产计数-当前日期生产总数`。 +3. 旧设备写入成功后，不能再按累计计数器做 delta-sum 累加 RT。 +4. 旧设备写入成功后，应把 RT 当天产量**直接覆盖为最新的今日累计值**。 + +### 2.2 Board1 机台状态需求 + +1. `board1` 的状态查询必须区分新旧设备。 +2. 旧设备状态来源：`BASE_DEVICE_PARAM_VAL` 当天最新一条三色灯为 `TRUE` 的状态参数。 +3. 新设备状态来源：月分表近两小时最新一条三色灯为 `TRUE` 的状态参数。 +4. `board4` 的状态统计必须复用 `board1` 的同一套后端口径，避免两个页面状态数量不一致。 + +### 2.3 Board4 设备总产量需求 + +1. 页面上的“设备总产量”必须返回各设备**历史累计总产量**。 +2. 历史累计总产量计算公式： + +```text +设备总产量 = SUM(DEVICE_DAILY_PRODUCTION.daily_prod) + RT_DAILY_PROD_STATE.current_total(当天) +``` + +3. 历史总产量不允许再直接回源表取 `BASE_DEVICE_PARAM_VAL` 或月分表的最新参数值。 + +### 2.4 Board5 当日产量 TOP5 需求 + +1. `board5` 的 TOP5 是“今日产量 TOP5”，不是“历史总产量 TOP5”。 +2. 统一从 `RT_DAILY_PROD_STATE` 取当天 `current_total` 排序。 +3. 百分比计算也统一基于 RT 的最大值，不再回源表取最大参数值。 + +--- + +## 3. 需求分析 + +### 3.1 为什么 PDA 不应继续写 `机台状态-实际产出数量` + +`机台状态-实际产出数量` 在当前方案里被当成“累计计数器型参数”使用，RT 更新逻辑也是围绕这个语义设计的： + +- 新值大于旧值：按差值累加 +- 新值小于旧值：视为计数器清零，按新值补量 +- 首条记录：只建立基线，不计产量 + +但 PDA 录入的是“今天已经产了多少”，本身就是**当天结果值**，不是设备累计计数器当前值。 + +如果继续把 PDA 今日值写成 `机台状态-实际产出数量`，会出现两个问题： + +1. 当天首笔录入会被 RT 当成“基线”，直接丢失首笔产量。 +2. 若后续人工修正把 120 改成 118，delta-sum 会误判为“清零重置”，反而把 118 再累加进去。 + +所以 OLD 设备的 PDA 今日产量与 NEW 设备自动采集累计计数器，**不是同一种语义层级的数据**，不能共用同一套 RT 更新算法。 + +### 3.2 为什么 OLD 设备 RT 应改为“覆盖模式” + +对于 OLD 设备，PDA 每次录入的值就是“截至当前时刻的今日总产量”，因此 RT 表中当天 `current_total` 的正确值应始终等于**最新一次 PDA 录入值**。 + +正确规则应为： + +1. 首次录入 100，RT=`100` +2. 再次录入 120，RT=`120` +3. 人工修正为 118，RT=`118` + +也就是说，OLD 设备 RT 更新规则应为： + +```text +RT.current_total = 最新 PDA 今日累计值 +``` + +而不是： + +```text +RT.current_total += 差值 +``` + +### 3.3 为什么 Board4 设备总产量不能直接查源表最新值 + +页面真实要的是历史总产量，而源表最新值只是某个时间点的参数快照： + +1. 对新设备，`机台状态-实际产出数量` 可能清零或回退，最新值不等于历史总产量。 +2. 对旧设备，PDA 今日累计值本来就只代表“今天”，更不等于历史总产量。 + +因此历史总产量必须从事实汇总层取数： + +- 历史已结算天：`DEVICE_DAILY_PRODUCTION` +- 当天实时部分：`RT_DAILY_PROD_STATE` + +### 3.4 为什么 Board5 TOP5 应直接查 RT + +`board5` 要的是“今天谁产得最多”，而 RT 本身就是全设备统一的“当天实时累计产量”结果表。 + +直接查 RT 的好处： + +1. 旧设备和新设备统一口径。 +2. 不需要分别扫旧表和月分表再汇总。 +3. 避免源表参数名不统一带来的 SQL 分叉。 +4. 与 `board4.dayTotal` 保持一致，便于验数。 + +### 3.5 为什么 Board1 状态查询必须旧设备取“当天最新”、新设备取“近两小时最新” + +新设备是高频采集，近两小时无数据通常意味着设备离线、采集异常或未开机，因此两小时窗口合理。 +旧设备三色灯由 PDA 事件驱动写入，不会像自动采集那样高频上报。如果也强行加两小时窗口，下午很容易把上午录过状态的旧设备误判成“未开机”。 + +所以状态窗口必须区分： + +1. 旧设备：当天最新 +2. 新设备：近两小时最新 + +--- + +## 4. 目标实现方案 + +### 4.1 统一分层 + +1. 源明细层 + - 旧设备：`BASE_DEVICE_PARAM_VAL` + - 新设备：`BASE_DEVICE_PARAM_VAL_YYYYMM` +2. 当天实时层 + - `RT_DAILY_PROD_STATE` +3. 历史日汇总层 + - `DEVICE_DAILY_PRODUCTION` + +### 4.2 统一统计口径 + +1. `board4.dayTotal`：查 RT 当天总和 +2. `board4.monthTotal`：查 DAY 当月累计 + 今天 RT +3. `board4.设备总产量`：查每台设备 `DAY 累计 + 今天 RT` +4. `board5.TOP5`：查 RT 当天每台设备 `current_total` + +### 4.3 RT 更新策略分流 + +#### NEW 设备 + +1. 来源参数：`机台状态-实际产出数量` +2. 写入位置：月分表 +3. 更新 RT 方式：数据库触发器 delta-sum + +#### OLD 设备 + +1. 来源参数：`生产计数-当前日期生产总数` +2. 写入位置：`BASE_DEVICE_PARAM_VAL` +3. 更新 RT 方式：Java Service 覆盖当天总量 + +### 4.4 RT/DAY 参数名的统一策略 + +虽然 OLD 设备源表写入的是 `生产计数-当前日期生产总数`，但 RT/DAY 作为统计事实表，建议继续统一使用： + +```text +param_name = '机台状态-实际产出数量' +``` + +这样做的原因： + +1. RT/DAY 面向的是“统一产量事实”，不是“来源参数原样搬运”。 +2. 下游 `Board4Mapper`、`Board5Mapper` 无需因为新旧设备来源不同而拆两套 SQL。 +3. 后续若还有别的来源参数接入，也可以统一沉淀到同一个统计事实口径。 + +--- + +## 5. 注意点 + +### 5.1 必须区分“源参数语义”和“统计事实语义” + +1. OLD 源参数是“今日累计值” +2. NEW 源参数是“累计计数器当前值” +3. RT/DAY 保存的是“统一统计产量事实” + +不能因为 RT/DAY 继续使用同一个 `param_name`，就误以为源数据语义也相同。 + +### 5.2 旧设备不能再走 delta-sum + +这条是本次方案最关键的边界。 +只要 PDA 输入值语义是“今天已经产了多少”，OLD 设备 RT 就必须走覆盖逻辑，而不能走差值累加逻辑。 + +### 5.3 Board4 文案与返回值必须一致 + +当前旧文档里把 `selectDeviceProductionAnalysis` 定义成“今日增量”，但页面标题是“设备总产量”。本次方案以页面真实语义为准，后端返回值改为历史总产量。 + +### 5.4 Board5 TOP5 不再直接扫源表 + +当 RT/DAY 链路跑通后，TOP5 不应再回源表按参数名硬查，否则会再次引入： + +1. 新旧设备源不同 +2. 参数名不同 +3. 算法不同 + +这三个分叉点。 + +### 5.5 Board1 与 Board4 状态必须复用同一接口口径 + +`board4` 不能自己另写一套设备状态统计 SQL。 +应继续复用 `aucma-base` 的状态统计接口，只修改底层 SQL 口径。 + +### 5.6 Oracle 11 兼容约束 + +1. SQL 继续使用当前项目已采用的 `ROW_NUMBER()`、`NVL()`、`TRUNC(SYSDATE)` 风格。 +2. 避免引入 Oracle 11 不支持的高级 JSON/递归查询写法。 +3. 动态分表名仍必须经后端受控生成，禁止前端透传表名。 + +--- + +## 6. 具体修改代码方案 + +## 6.1 修改 PDA 当日产量写入参数 + +### 文件位置 + +`zs_aucma-mes-back/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java` + +### 修改目标 + +1. 把 PDA 当日产量写入参数从 `机台状态-实际产出数量` 改为 `生产计数-当前日期生产总数` +2. 保留源表完整时间序列，供追溯查询使用 + +### 建议代码 + +```java +// 文件：zs_aucma-mes-back/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java + +private static final String PARAM_NAME_PDA_DAILY_TOTAL = "生产计数-当前日期生产总数"; + +/** + * PDA-选择设备后更新当日产量（写入参数：生产计数-当前日期生产总数） + */ +@PostMapping("/device/updateDailyOutput") +@Transactional(rollbackFor = Exception.class) +public AjaxResult updateDeviceDailyOutput(@RequestBody DmsPdaDeviceParamUpdateVo request) { + if (request == null) { + throw new ServiceException("请求体不能为空"); + } + return updatePdaDeviceParamValue( + request.getDeviceCode(), + request.getDeviceId(), + request.getParamValue(), + PARAM_NAME_PDA_DAILY_TOTAL, + true, + "当日产量" + ); +} +``` + +### 行间注释要求 + +```java +// 为什么这样做：PDA 录入的是“今天已经产了多少”， +// 它在业务语义上就是“生产计数-当前日期生产总数”，不能再伪装成累计计数器参数。 +``` + +## 6.2 新增 OLD 设备 RT 覆盖写入能力 + +### 文件位置 + +1. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java` +2. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java` +3. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java` + +### 修改目标 + +1. OLD 设备写入 `生产计数-当前日期生产总数` 后，直接覆盖 RT 当天总量 +2. RT 中的 `param_name` 继续统一写为 `机台状态-实际产出数量` + +### 建议接口 + +```java +// 文件：IRtDailyProdStateService.java + +void overwriteTodayProduction(String deviceCode, String paramName, BigDecimal todayTotal, Date collectTime); +``` + +### 建议实现 + +```java +// 文件：RtDailyProdStateServiceImpl.java + +@Override +@Transactional(rollbackFor = Exception.class) +public void overwriteTodayProduction(String deviceCode, String paramName, BigDecimal todayTotal, Date collectTime) { + if (deviceCode == null || paramName == null || todayTotal == null || collectTime == null) { + return; + } + + Date prodDate = truncateToDay(collectTime); + RtDailyProdState state = rtDailyProdStateMapper.selectForUpdate(prodDate, deviceCode, paramName); + Date now = new Date(); + + if (state == null) { + RtDailyProdState insertState = new RtDailyProdState(); + insertState.setProdDate(prodDate); + insertState.setDeviceCode(deviceCode); + insertState.setParamName(paramName); + insertState.setLastParamVal(todayTotal); + insertState.setCurrentTotal(todayTotal); + insertState.setResetCount(0L); + insertState.setDirtyFlag(0L); + insertState.setLastCollectTime(collectTime); + insertState.setUpdateTime(now); + rtDailyProdStateMapper.insertRtDailyProdState(insertState); + return; + } + + // 为什么这样做：OLD 设备上报的是“今天当前总量”， + // 这里必须直接覆盖 RT 结果，不能按差值累加，否则人工修正会把产量越改越大。 + state.setLastParamVal(todayTotal); + state.setCurrentTotal(todayTotal); + state.setLastCollectTime(collectTime); + state.setUpdateTime(now); + rtDailyProdStateMapper.updateRtDailyProdState(state); +} +``` + +### Base Service 路由建议 + +```java +// 文件：BaseDeviceParamValServiceImpl.java + +private static final String DAILY_OUTPUT_PARAM_NAME = "机台状态-实际产出数量"; +private static final String PDA_DAILY_TOTAL_PARAM_NAME = "生产计数-当前日期生产总数"; + +private void syncRtStateIfNeeded(BaseDeviceParamVal entity, int rows) { + if (rows <= 0 || !deviceParamTableRouter.isOldDevice(entity.getDeviceCode())) { + return; + } + + try { + BigDecimal newVal = new BigDecimal(entity.getParamValue()); + + if (PDA_DAILY_TOTAL_PARAM_NAME.equals(entity.getParamName())) { + // 为什么这样做：OLD 设备源数据是“今日累计值”， + // RT 要保存的是当天权威总量，因此采用覆盖模式。 + rtDailyProdStateService.overwriteTodayProduction( + entity.getDeviceCode(), + DAILY_OUTPUT_PARAM_NAME, + newVal, + entity.getCollectTime() + ); + return; + } + + if (DAILY_OUTPUT_PARAM_NAME.equals(entity.getParamName())) { + // 保留历史兼容能力：如果旧链路仍写累计计数器参数，则继续按旧规则处理。 + rtDailyProdStateService.incrementProduction( + entity.getDeviceCode(), + entity.getParamName(), + newVal, + entity.getCollectTime() + ); + } + } catch (NumberFormatException ex) { + log.warn("OLD设备产量值不是合法数字，跳过RT同步 | deviceCode={}, paramValue={}", + entity.getDeviceCode(), entity.getParamValue()); + } +} +``` + +## 6.3 修改 Board1 状态 SQL + +### 文件位置 + +`zs_aucma-mes-back/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml` + +### 修改目标 + +1. 旧设备：当天最新三色灯 +2. 新设备：近两小时最新三色灯 + +### 建议 SQL 结构 + +```xml + + + +``` + +### 行间注释要求 + +```xml + +``` + +同样的窗口规则要同步应用到： + +1. `selectDeviceStatusStatistics` +2. `selectDeviceStatusList` + +## 6.4 修改 Board4 设备总产量 SQL + +### 文件位置 + +`zs_aucma-mes-back/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml` + +### 修改目标 + +将 `selectDeviceProductionAnalysis` 从“今日 RT”改为“历史总产量”。 + +### 建议 SQL + +```xml + + + +``` + +### 行间注释要求 + +```xml + +``` + +## 6.5 修改 Board5 TOP5 SQL + +### 文件位置 + +`zs_aucma-mes-back/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml` + +### 修改目标 + +1. `selectProductionTop5` 改为直接查 RT +2. `selectMaxProduction` 改为直接查 RT + +### 建议 SQL + +```xml + + + + + +``` + +### 行间注释要求 + +```xml + +``` + +--- + +## 7. 代码文件位置汇总 + +### 必改文件 + +1. `zs_aucma-mes-back/aucma-dms/src/main/java/com/aucma/dms/controller/DmsMobileController.java` +2. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/IRtDailyProdStateService.java` +3. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/impl/RtDailyProdStateServiceImpl.java` +4. `zs_aucma-mes-back/aucma-base/src/main/java/com/aucma/base/service/impl/BaseDeviceParamValServiceImpl.java` +5. `zs_aucma-mes-back/aucma-base/src/main/resources/mapper/base/BaseDeviceParamValMapper.xml` +6. `zs_aucma-mes-back/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml` +7. `zs_aucma-mes-back/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml` + +### 需同步确认但本次可不改的文件 + +1. `zs_aucma-mes-ui/src/views/board/board1/index.vue` +2. `zs_aucma-mes-ui/src/views/board/board4/index.vue` +3. `zs_aucma-mes-ui/src/views/board/board5/index.vue` +4. `zs_aucma-mes-back/aucma-base/src/main/resources/board4_end_to_end_full_implementation_guide.md` +5. `zs_aucma-mes-back/aucma-base/src/main/resources/梳理.md` + +说明： + +前端接口名本次可保持不变，主要修正后端返回语义；但旧文档中“设备总产量=今日增量”的描述必须后续同步修正，避免再次误导实现。 + +--- + +## 8. 验证清单 + +### 8.1 OLD 设备 PDA 录入验证 + +1. 09:00 录入 OLD-01 当日产量 `100` + - 源表写入参数名应为 `生产计数-当前日期生产总数` + - RT 中 OLD-01 当天 `current_total=100` +2. 11:00 再录入 `120` + - RT 应直接变为 `120` +3. 11:30 修正为 `118` + - RT 应直接变为 `118` + - 不允许变成 `238` + +### 8.2 Board1 状态验证 + +1. OLD 设备上午 9 点录入“暂停”，下午 3 点未再录入 + - `board1` 仍应显示“停机/暂停” +2. NEW 设备超过两小时无采集 + - `board1` 应按无有效状态数据处理 + +### 8.3 Board4 历史总产量验证 + +1. `DEVICE_DAILY_PRODUCTION` 中某设备历史累计 `3000` +2. `RT_DAILY_PROD_STATE` 当天 `200` +3. 页面“设备总产量”应显示 `3200` + +### 8.4 Board5 TOP5 验证 + +1. 取 RT 当天数据做排序 +2. TOP5 与 `board4.dayTotal` 的设备明细求和口径应一致 + +--- + +## 9. 最终结论 + +本次业务梳理后的关键结论只有三条： + +1. OLD 设备 PDA 录入值是“今日累计值”，因此源表应写 `生产计数-当前日期生产总数`，RT 更新必须走**覆盖模式**。 +2. NEW 设备自动采集值是“累计计数器当前值”，因此继续通过月分表触发器按 **delta-sum** 更新 RT。 +3. 所有大屏统计最终都应尽量读取 RT/DAY 事实层，而不是重新回源表拼业务逻辑。 + +只要这三条不被打破，`board1`、`board4`、`board5` 的状态、今日产量、历史总产量三套口径就能统一起来。 diff --git a/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml b/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml index 7a78389..3da6eb4 100644 --- a/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml +++ b/aucma-report/src/main/resources/mapper/report/Board4Mapper.xml @@ -150,17 +150,27 @@ ) WHERE ROWNUM <= 10 - + diff --git a/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml b/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml index 570bc36..c278370 100644 --- a/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml +++ b/aucma-report/src/main/resources/mapper/report/Board5Mapper.xml @@ -102,40 +102,30 @@ - - +