V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
nicolassggsuper
V2EX  ›  问与答

请教多级分销,取下级和下下,下下下级...获取订单思路

  •  
  •   nicolassggsuper · 2020-02-28 09:10:46 +08:00 · 3779 次点击
    这是一个创建于 1715 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现有账户表 t_user,订单表 t_order ,两张表通过 userid 关联。
    t_user 内部有上下级关系 级别 LV1 LV2 LV3... LVn

    需求:LV1 可以看到 lv2 级 lv2 所有下级,下下级的订单信息,其他级别以此类推;
    备注:lv1 的 lv2 级别用户可能有多个

    目前解决方式: 获取 lv1 得所有 lv2 级 lv2 所有下级,下下级的...用户的 userid,然后取 t_order 表中查找( select * from t_order where uid in (***,****,***))

    问题:数据量小得化,系统还能扛得住,假设 lv2 级别得用户有 1W,感觉紧紧一个查询,数据库就吃不消。


    请教这种情况改怎么破?
    30 条回复    2020-02-28 16:11:03 +08:00
    nicolassggsuper
        1
    nicolassggsuper  
    OP
       2020-02-28 09:18:47 +08:00
    编辑时,点击太快,发布出来了。 求指点
    sunjiayao
        2
    sunjiayao  
       2020-02-28 09:26:08 +08:00
    前段时间刚做过一个。最后实现的大概思路是,先使用闭包表建立关系方便查询下线,订单表使用两张,一张原始订单记录,一张存储父子级关系与步长。
    absolutely
        3
    absolutely  
       2020-02-28 09:26:38 +08:00
    无限极?
    sunjiayao
        4
    sunjiayao  
       2020-02-28 09:29:21 +08:00
    @sunjiayao #2 自动发布了
    第二张订单表字段大概可以设计为
    订单 id | 购买用户 id | 上线 id | 上下级步长 | 若有佣金也可以存该表
    另外提醒一下:佣金分红超过三级违法哦
    nicolassggsuper
        5
    nicolassggsuper  
    OP
       2020-02-28 09:40:59 +08:00
    @absolutely 可能是 10 级
    reus
        6
    reus  
       2020-02-28 09:41:25 +08:00
    超过三级就是传销,要进去的,小心了
    reus
        7
    reus  
       2020-02-28 09:44:14 +08:00   ❤️ 1
    @nicolassggsuper 10 级? 3 级都算擦边球了,之前封了一大批,10 级就是明送,如果你不是老板,赶紧跑路。
    nicolassggsuper
        8
    nicolassggsuper  
    OP
       2020-02-28 09:46:08 +08:00
    @sunjiayao 我们不涉及到佣金分红,感谢提醒。请问: 上下级步长 指的是? 如果 LV5 购买了 1 一个订单,上级是 LV4,那么 第二张订单保重存储几条记录? 上下级步长是几?
    nicolassggsuper
        9
    nicolassggsuper  
    OP
       2020-02-28 09:46:49 +08:00
    @reus 我们不涉及到佣金分红,谢谢
    sunjiayao
        10
    sunjiayao  
       2020-02-28 09:56:58 +08:00
    @nicolassggsuper #8 就是第几级下线的意思。如果你们需要记录十级(含)下线的订单关系,那所谓的步长最大就是 10。
    当 LV5 购买一个订单时。在创建原始订单后,要将其和其所有上级分别生产一条记录订单(数据量可能比较大,但没关系)。
    即为:
    LV1 | LV5
    LV2 | LV5
    .
    .
    .
    .
    nicolassggsuper
        11
    nicolassggsuper  
    OP
       2020-02-28 10:01:10 +08:00
    @sunjiayao 明白了,感谢,非常感谢!
    mjVtb96d2bap2u3Z
        12
    mjVtb96d2bap2u3Z  
       2020-02-28 10:49:02 +08:00
    @sunjiayao 如果涉及到上下级关系中途变更的,怎么处理比较好?
    optional
        13
    optional  
       2020-02-28 11:05:55 +08:00
    树形结构有两种实现方式,
    一种是 parent_id 方式存储, 这个可以用 cte 递归查询实现
    一种是 path 前缀树方式存储, 查询直接 like prefix%就行。
    前者调整灵活但是查询效率低,后者查询效率高但是灵活性少一点,实现的时候也可以两种都实现,在修改 parent_id 的时候同时保存前缀。
    troycode
        14
    troycode  
       2020-02-28 11:19:59 +08:00
    存储过程来读吧
    DoubleShut
        15
    DoubleShut  
       2020-02-28 11:23:25 +08:00
    同 13 楼,两种方式都实现
    luckyrayyy
        16
    luckyrayyy  
       2020-02-28 11:32:00 +08:00
    是否可以直接缓存一个全体人员关系树?到时候能直接取到所有下级子树的 id。
    nicolassggsuper
        17
    nicolassggsuper  
    OP
       2020-02-28 11:36:15 +08:00
    @luckyrayyy 人员关系树缓存不是问题,按照 @optional 的方式也可以。 但最终需要的获取具体订单的性能
    luckyrayyy
        18
    luckyrayyy  
       2020-02-28 11:39:25 +08:00
    @nicolassggsuper 你的问题是最后怎么读这么多订单?这不是得分页么
    sampeng
        19
    sampeng  
       2020-02-28 13:13:01 +08:00 via iPhone
    不要用 parentid 的方式。用二叉树实现。无限分类
    yikyo
        20
    yikyo  
       2020-02-28 13:39:06 +08:00
    数据库读多写少的树型结构,可用左右值模式,限制只能有一个根。
    HonoSV
        21
    HonoSV  
       2020-02-28 14:09:02 +08:00
    mark,我现在这个项目也是做分销。13 楼提到的 parentId 和 path 方式都有用到。
    jayin
        22
    jayin  
       2020-02-28 14:16:21 +08:00
    上面的做法我都想过,也实践过。最后做法是,维护一个关系表 relation 表,记录用户 A 的所有下级用户 ID+用户层级。维护这个表是复杂点,但是各种查询性能快、简单。
    nicolassggsuper
        23
    nicolassggsuper  
    OP
       2020-02-28 14:17:29 +08:00
    @optional @HonoSV parentId 和 path 方式用在用户关系设计上?还是订单上也用到了这种关系?
    nicolassggsuper
        24
    nicolassggsuper  
    OP
       2020-02-28 14:18:37 +08:00
    @jayin 你这种思路是可行的,并且效率能接受
    HonoSV
        25
    HonoSV  
       2020-02-28 14:32:39 +08:00
    @nicolassggsuper 我们只用在 user 表上,所以订单展示要联一次表,因为用户量不大,所以还没啥性能问题。。。mark 也是看看还有没有更好的方案。
    sun019
        26
    sun019  
       2020-02-28 14:41:21 +08:00
    无限极分类吧 13 楼说的第一种
    keepsmilence
        27
    keepsmilence  
       2020-02-28 14:43:24 +08:00
    现在习惯设计关系表是都有 parent_id 和 parent_ids ( path )两个字段,parent_id 记录所属上级 id,parent_ids 从所属上级记录读取它的 parent_ids 后追加上级 id,逗号分隔;如果需要修改关系,修改后从新的关系更新 parent_ids ;之后查询就像上面那样,用「 like ,XXX,%」查询出所有下级 id (注意加了前后逗号,避免通配)后再用 id 集合查出订单;
    keepsmilence
        28
    keepsmilence  
       2020-02-28 14:47:47 +08:00
    噢,还有,如果任意一级更新了 parent_id,除了要从他的上级继承 parent_ids 之外,还要有个触发机制更新所有下级的 parent_ids
    optional
        29
    optional  
       2020-02-28 14:55:05 +08:00
    @nicolassggsuper 当然是用户了,订单上有需要去 join 啊
    doublleft
        30
    doublleft  
       2020-02-28 16:11:03 +08:00
    在前段用点击触发下钻可以么,节省很多
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5374 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 08:53 · PVG 16:53 · LAX 00:53 · JFK 03:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.