“统计集团下面所有部门的销售额”并没有说明集团节点是否也记录订单、组织关系按哪个日期生效，以及同一部门能否有多个上级。递归 SQL 能找到路径，却不能替业务决定路径上的金额应累计几次。本文按 PostgreSQL 18 的语义讨论组织森林，再单独处理多父级图；所有数据均为构造示例，未运行数据库实验。
先分开节点集合、到达路径与业务事实
多表关联的重复计数已经说明，金额应按事实身份核对。层级查询增加了一种更隐蔽的放大：同一个部门可能被不同起点或不同路径多次到达。必须先确定想要的是部门集合、全部路径，还是按路径展开后的数量，再决定是否去重。
设某租户的一版组织关系为：G 是根，A 和 B 的上级是 G，C 的上级是 A。A、B、C 各有一笔订单，金额分别为 100、200、50 元，G 无直接订单。若问题是 G 及全部下级的销售额，部门集合为 G、A、B、C，三笔订单合计 350 元。根节点应包含在集合内，否则真实数据里挂在根上的订单会漏算。
若同时请求 G 与 A，输出两行各自子树的结果，则 G 为 350 元、A 为 150 元，各行可以都正确，但两行合计 500 元不是集团总额，因为 A 与 C 被覆盖两次。若业务要的是两者覆盖范围的并集，答案应仍为 350 元。输出分组是否互斥，应成为指标定义的一部分。
实施前固定 tenant_id、hierarchy_version、node_id、parent_id 的含义，并明确事实唯一键、金额单位、状态和时间范围。名称不能充当节点身份；同名部门、不同租户复用编号和历史版本复用编号都很常见。模型生成查询前，应拿到这一契约以及获准使用的组织范围。
外键能限制父节点存在，不能证明整张表是一棵树
PostgreSQL 的约束文档给出了自引用外键：父节点为空可表示顶层节点，非空父节点必须引用已有记录。[2] 在本例的数据模型中，可将 tenant_id、hierarchy_version、node_id 设为复合主键，并让带相同租户与版本的 parent_id 引用这组键；租户与版本列应非空，根节点仅允许 parent_id 为空。
但 A 指向 B、B 又指向 A，两边父节点都存在，仍然形成环。增加 parent_id 不等于 node_id 的逐行检查，只能排除自环，不能排除较长环。无环、根数量和全部节点可达，属于需要额外验证的结构属性，不能从外键通过推导出来。
全量导入前先检查重复节点身份、跨租户或跨版本的父引用、缺失父节点及自环，再检查多节点环和预期根。遗留数据中找不到父节点的记录应隔离并给出清单，不要自动改为根；否则金额可能被重新归入一个看似正常的顶层组织。
若业务是森林，可以有多个合法根；若要求一棵树，应验证只有一个根且所有节点可达。只从合法根向下遍历，会漏掉一个独立的循环分量。因此要核对所有节点与根可达集合的差集，并对未覆盖部分继续诊断，不能把“没有查到环”解释为全表无环。
递归展开要保留异常证据，不用截断伪装完整
在单父级模型中，先选定租户、组织版本和获准根节点作为起点，再反复用子节点的 parent_id 匹配当前 node_id，且每一步都保持租户与版本相同。建议输出 root_id、node_id、depth 及诊断路径。depth 从零开始时，根节点为零；起点规则与向下连接方向应在代码审查中明确。
PostgreSQL 18 支持 CYCLE 子句记录访问路径并标出循环行，也支持手动维护已访问节点数组。[1] 这里的环判断必须采用完整节点身份，或在查询已固定租户与版本的前提下使用 node_id。循环标记行是异常证据，不能只过滤掉后就把剩余小计当作认证结果。
把 UNION ALL 改成 UNION 不是通用的防环办法：如果结果包含不断增长的 depth 或 path，再次访问同一节点时整行仍可能不同。[1] 同样，最外层 LIMIT 不是可靠的生产防护；排序或关联可能要求先读完递归结果。应有明确的执行超时、资源预算和深度边界，并把触及边界作为未完成状态。
深度上限只能限制工作量，不能证明结构正确。若允许最大深度为二，而深度二节点仍有合法子节点，必须报告结果被截断。宽而浅的图还可能产生大量路径，即使没有超过深度上限也会消耗资源。应监控展开节点数、路径数和执行时间，并对异常结果停止金额发布。
按节点汇总时去重身份，按路径展开时保留业务乘数
对组织子树销售额，建议先生成每个 root_id 下唯一的 node_id 集合，再与符合条件的订单事实关联。每笔订单有且只有一个经确认的归属部门时，每个根内应只贡献一次；不同根之间可能重叠，报告必须说明这些行不能直接相加。用于多个根覆盖并集的查询，则先跨根得到唯一部门集合。
若组织允许多父级，用独立的边表表达关系，并先决定它是管理归属、协作关系还是分摊关系。例如 G 到 A、G 到 B，A 与 B 都到 C；C 的一笔 50 元订单沿两条路径到达 G。若统计 G 覆盖的唯一部门，应贡献 50 元，而不是 100 元；若需要向两个责任中心分摊，则必须另有经批准且合计为一的权重。
不能用金额 DISTINCT 修复：A 与 C 即使各有一笔 50 元订单，也是两笔不同事实。应以订单身份和目标根身份检查贡献次数。若同一个订单对应多个归属部门且没有分摊规则，这不是递归语法问题，应停止认证汇总并返回歧义记录。
物料清单是关键反例。若每件 P 需要两个 A 与三个 B，每个 A 需要四个 X，每个 B 需要五个 X，则每件 P 共需 2×4+3×5=23 个 X。这里两条路径表达不同用量，应沿路径连乘后累加；把 X 节点去重只保留一次会破坏数量语义。这个算例没有损耗、替代件或单位换算，真实 BOM 必须另外定义这些规则。
固定关系版本，再比较邻接表、闭包表与路径存储
组织调整时，当前父子关系不能直接用于所有历史问题。按交易发生时归属、按当前组织重算，以及按当时报表版本复现，是不同要求。本文建议给认证报表绑定一个已验证的关系版本；需要时态计算时，再设计有效期及唯一有效版本检查，不能把新旧关系混在一次展开里。
邻接表保存直接父子关系，更新相对直观，但查询时需要展开。闭包表预存祖先与后代的关系，可降低重复查询工作；代价是移动子树、删除边或修改版本时，需要同步维护并验证派生关系。组织集合的闭包唯一键通常包含版本、祖先、后代；若要表达路径数量或 BOM 乘数，不能只靠这张集合表。
PostgreSQL 的 ltree 扩展可存储层级标签路径，提供祖先、后代判断以及相应索引支持。[3] 它适合评估为路径查询的实现选项，但不是自动治理机制。节点改名是否改变路径、移动子树如何更新后代、多父级是否保存多条路径，都仍需由应用定义并验收。
高频查询可以使用经过验证的派生结构，低频或变化频繁的关系可以按需展开。不要只比较一次查询耗时，还要计入更新放大、重建时间、存储与版本切换成本。新版本准备完成后，先核对结构和控制总额，再切换读取指针；失败时保留原认证版本，不发布一半更新的关系。
以反例和集合对账验收完整性
第一组使用前述 G、A、B、C 数据，核对 G=350、A=150，以及 G 与 A 覆盖并集=350；再向根 G 增加一笔 20 元订单，G 应变为 370，A 不变。第二组增加同金额但不同订单编号的事实，结果应正常增加，用来揭穿按金额去重。
第三组注入缺失父节点、自环、双节点环、独立循环分量及错误版本引用。要求识别异常并阻止认证发布，不能仅以查询结束作为通过。第四组加入菱形多路径，分别验证唯一部门集合和路径数量；再用 23 个 X 的 BOM 例子验证两种语义不会混用。
第五组检查边界：无订单部门应仍可进入组织范围；无权访问的节点和事实按明确授权规则处理，不能借递归越权。若权限裁剪会使用户看到不完整子树，应在结果中说明范围，不能标成完整集团。深度截断、超时和派生表版本落后都应返回可识别的未完成状态。
最后把预期部门集合、实际部门集合、未覆盖节点、每个根内的事实重复贡献数与独立事实控制总额一起保存。只比较最终总额可能让一笔漏算与另一笔重复相互抵消。本文给出的是可执行的验收设计与语义推导，落地时应在目标数据库、权限配置和真实规模上运行，保留原始结果后再作性能与正确性承诺。