层级查询的使用者痛点

过程中，我们经常会遇到层级查询需求：

• 查某个部门及其所有下级的销售额；
• 查某个商品分类下面所有子分类的库存；
• 查某个大区下面所有省、市、门店的订单；
• 查某个节点的直接下级；
• 查某个员工所在组织往上的完整方法。

parent_id 只能表达一层关系

parent_id 表达的是一条边。它能告诉你：A 的父节点是谁，或者哪些节点的父节点是 A。但业务问的通常不是“一条边”，而是一段范围。

比如“查技术中心下面的所有团队销售额”，这里至少有几种可能：

• 只查技术中心自己；
• 查技术中心的直接下级；
• 查技术中心下面所有层级的团队；
• 查技术中心自己和所有下级；
• 按技术中心汇总成一行；
• 按每个下级团队分别展示明细。

"如果只给接口传一个 parentId ,后端就必须再补很多隐含约定！"

• "要不要包含自身？"
• "只查一层还是查所有层？"
• "最多可以展开几层？"
• "是向上还是向下？ "
• "结果是需要汇总还是拆解？"
• "这些问题在业务逻辑中很容易被混淆！"
• "各自独立实现动态SQL时又容易导致重复代码！"
• "而且后期维护成本极高！"
.

同一个节点，有多种不同语义!

拿组织树举例。假设T001 是“总部”。如果只是简单传参数team$id = T001 ,业务可能会要求:

• "我要看这个部门本身 "
• "我要看这个部门的一级子部门 "
• "我要看这个部门及其全部子孙 "

这代表着仅靠一个简单参数根本无法满足需求!更不用说后端还需要处理这些特殊逻辑:

 childrenOf // 直接下级
descendantsOf // 所有后代
selfAndDescendantsOf // 自身+后代
ancestorsOf // 所有祖先
selfAndAncestorsOf // 自身+祖先

默认视角不能有魔法!

更麻烦的是,普通维度和层次维度混用时容易产生误解!例如:

{ "columns":,"groupBy":。"slice": }

这样写默认应该精确匹配T001,而不能因为team恰好是父子维度就自动展开全部子孙!否则将导致:

• 返回数据与预期不符!
接口调用方无法控制范围!

DSL需要明确边界!

通过语义化声明式语言。可以:

统一标准化操作符如: - childrenOf - descendantsOf - ancestorsOf - selfAndAncestors - maxDepth

这样既能避免重复实现,又能让调用方清晰表达意图!

小结!