Oracle Pipelined function返回前能否编辑数据 应收链路去重

• Pipelined Function 不支持在数据正式返回前遍历管道内数据集、执行update/delete操作完成去重
  Pipelined函数的核心逻辑是流式计算、逐行返回，行数据一旦通过PIPE ROW语句输出，就会直接推给调用方，不再受当前函数的上下文管控，不存在“暂存全量管道数据、待全部计算完成后修改再返回”的机制。如果硬要攒完全量数据再修改去重，会完全丧失Pipelined函数低内存占用、流式返回的优势，没有实际意义。
• 不需要额外编写独立的后置校验函数做去重。后置遍历全量结果去重会产生额外的数据集扫描开销，完全可以把去重逻辑嵌入链路追溯的主流程，从数据生成的根源解决重复问题。

你现在遇到的数值重复问题，本质是纯递归遍历多根聚合链路时，同一个底层应收节点会被多条递归路径重复访问、重复计算，和返回方式没有关系，按下面的逻辑实现就能解决：

1. 替换无状态的纯递归遍历逻辑，不管是用递归CTE还是保留PL/SQL递归函数，都要加已访问节点标记的判断：
   用PL/SQL的话就在函数内声明一个以Receivable ID为键的关联数组当访问缓存，每次处理某笔应收记录前先判断ID是否存在于缓存中：
   • 已存在：直接跳过，不做记录拉取、不输出管道行
   • 不存在：先把ID写入缓存，再拉取该笔应收的变动记录、执行PIPE ROW输出，之后再递归处理关联的上下游节点
     这个拦截逻辑发生在数据输出到管道之前，完全符合Pipelined函数的执行规则，也不会破坏流式返回的性能。

   对应你举的业务示例：A0、A1、A2聚合生成B，后续链路到D。从D往上追溯时，第一次访问到A0/A1/A2就标记为已访问，后续递归路径中再碰到这三个ID直接跳过，从根源上避免重复计算。

2. 最终结果校验只需要校验New Node字段的唯一性即可：每笔应收的重组、变动记录只会对应唯一的新节点ID，只要这个字段没有重复，就不会出现数值重复累加的问题，不需要全字段比对。
3. 如果链路数据量级超过10万，优先用递归CTE替代PL/SQL递归函数做追溯，数据库原生的递归CTE对访问标记、路径去重的优化远好于自定义递归函数，性能会高3~10倍。

以下写法不推荐，会引入额外问题：

• 不要把Pipelined函数输出的全量数据写入临时表后再做update/delete去重：会多产生一次全量数据写入、扫描的开销，数据量大时性能下降明显
• 不要靠最外层查询加DISTINCT去重：DISTINCT只能去除字段完全一致的重复行，你遇到的重复是节点被重复遍历导致的数值计算错误，很多重复行的字段值不完全一致，DISTINCT无法处理
• 不要保留无访问标记的递归逻辑：多根聚合场景下递归路径会随链路层级增加指数级上涨，数据量稍大就会触发递归层级超限的报错。

内容的提问来源于stack exchange，提问作者Hommee