无限级别分佣模式设计

[rootx]

A 邀请了 B C

B 邀请了 D E
C 邀请了 F G

D 邀请了 1 2
E 邀请了 3 4
F 邀请了 5 6
G 邀请了 7 8

当前 A 是团长 BCDEFG12345678 均为会员 因为他们都是 A 这条线带出来的 他们的消费 A 都可以获得佣金

突然 B 升级成为了团长 则需要把 B 这条线带出来的用户都找出来并归给 B：DE1234

查出 B 这条线所有用户 除了数据库记录上级关系 程序用递归法遍历 因为深度未知 所以该方案操作耗时位未知 并且可能随着时间的推移 越顶层的人升级 需要遍历的就越久

还有其他更优雅更快速的方式实现吗？无论是从数据库设计还是程序上。

[moult]

这不是花生日记的模式吗？
增加一个字段记录团长 ID，每天凌晨把所有的用户和上下级关系读取出来，没必要的字段就不要查询了，然后递归进行处理就好了，处理环节用不了多少内存和计算资源，就是一开始读取所有用户到内存的时候吃力点，所以要凌晨要批量处理。

[Olament]

Disjoint set?

[Olament]

@Olament 看错需求了 当我没说

[whileFalse]

我记得三级以上的分俑是犯法的？

[geelaw]

缓存你的答案，每次加一个人只会改变高度个数的缓存。

[gzlock]

@whileFalse 所以楼主赶紧辞职或者自首？

[lovestudykid]

@whileFalse 程序员作为正义的化身，自然不受法律约束啦

[lovestudykid]

PS>没有任何针对楼主和楼上诸位技术讨论的意思。只是不认同对法律问题不以为然的态度，以反话对反话。

[houlin]

这个不算三级分销，按照遍历的逻辑，当 B 成为团长时，A 和 B 就已经不是层级关系了，也就是说在规则上如果 B 是团长的话，A 不再从 B 及 B 以下获取佣金就不属于三级分销了。其实这是两个进程，一是人员等级问题，A 的等级树，二是分佣规则的制定，A 获取 B 及以下和 A 仅获取 B 是不同的。那么我们程序在设计的时候其实是在做程序一，而程序二就看产品经理怎么定了

[ebony0319]

查并集。这种一次查询不是很好查，要写一个视图，一个函数。视图实习的功能是查找所有子。函数的功能是从自己开始一层层找上集（从下而上），找到第一个非团长。

[jacobz]

@ebony0319 并查集不合适吧

[xuanbg]

超过 3 级就是传销，楼主赶紧投案自首吧

[respect11]

mysql 的 closure table

[imnpc]

我的做法是只更改 B 以及 B 的下级的 teamid 需要递归处理，
用户表内记录用户的上级 pid 以及 当前所属 teamid，
B 团队离开 A 线，B 的上级 pid 归 0，无限极查询 B 的所有下级 id, 更改 teamid 为 B 的 id
因为这里不递归处理的话 订单那边进行分佣计算的时候也要递归

[rockyou12]

似乎可以考虑用图数据库？

[TangMonk]

递归

[Mohanson]

用 simple merkle tree. A 的 id 是 10， 则 B 的 id 是 10-11, 依次类推，当你找到一个用户，其所有上级都是确定的。

[Mohanson]

千万别用个字段记录上级 id， 这种对数据库的压力是指数级别增长的

[Mohanson]

错了，是 trie 树， 还没睡醒

[abcbuzhiming]

第一，国家现在好像严打多级分佣。
第二，程序员讨论的是技术问题，这个技术问题从本质是如何从理论上无限极的树里把把 1 个节点的子节点全部查出来。记录父 id 的方式是不行的，深度到一定程度后指数级别的增加计算压力，有一种 AB 树的记录方案，但是仍然有弱点。
我也希望能看到更好的算法