月末结算窗口里，几万张订单等待检查，有些需要补全状态，有些需要重新计算金额，还有些必须调用业务对象完成正式过账。操作人员看到的是同一个「执行」按钮，开发人员面对的却是三种不同性质的工作。若把它们塞进一个循环，逐张读取、逐张更新、逐张提交，程序看起来像连续落雷，实际可能只是数据库与应用服务器之间来回奔跑。赵灵儿的「狂雷」适合用来理解这种场景。它给人的印象不是对单个目标轻轻点一下，而是在一定范围内集中释放力量，让多个目标同时承受攻击。放到 ABAP 世界，我会把「狂雷」解释为一套面向大量业务对象的集中处理方案，先确定命中范围，再选择合适的执行层，控制并发和资源消耗，并为每一次成功或失败留下可核查的结果。这只是工程类比。ABAP 没有名为「狂雷」的关键字，也不存在一条语句能安全地替所有业务对象完成批量修改。真正有价值的问题是，同样面对十万条记录，哪些工作应交给 SAP HANA 的集合运算，哪些工作应分配给多个 ABAP 工作进程，哪些工作必须通过正式的业务接口逐项完成。从「攻击范围」谈起，最像雷云笼罩一片区域的，是数据库集合运算。假定我们的系统有一张自建待处理表，每条记录带有地区和状态。管理人员希望知道各地区还有多少待处理订单。逐条读取订单，在 ABAP 内表中累计，当然能够得到数字；但数据量大时，我们搬运了许多原始记录，只为了得到少量汇总结果。数据库本来就擅长筛选、分组和聚合，此时把计算放在数据库一侧更合适。下面的示例假设zorder_queue是我们自己设计、允许当前程序读取的持久化表，字段region与status已存在。它展示的是只读统计，不是对标准销售订单表直接动手。