问答 / 8 / 20 / 创建于 3年前
目前有这样一个需要,除去自身平台外,还有一级代理和二级代理。包括平台本身的话,应该就是三级。目前有个需求就是,平台的下的订单,有可能是直接从平台下单,也有可能从一级代理或二级代理的渠道下单。所以我的想法是直接订单直接绑定一个代理的id,但是有个问题就是,订单列表在筛选的话,怎么能筛选和查询出对应的订单。
平台的话,能查看所有的订单。二级代理能看到自己的直接订单和下面三级代理的订单。三级订单只能查看到自己的订单。请问下是从数据表结构设计下手吗?订单列直接冗余出两个字段来存储二级和三级的id,但是感觉也不好。
中间关联表?es分词?
什么都es 。 我建议中间表搞定。
冗余字段吧,我看到别人一个表100个字段都有
订单量不大的话表结构
这样行不:
代理表 (ID,父ID,代理名称)和订单表 (ID,代理ID,……)
查订单时,先从代理表中,查出当前和所有下属代理,然后再到订单表中查找?
前者可通过 CTE 实现,或者手动查出后,WHERE 代理ID IN (a, b, c, d, ……) ?
CTE
WHERE 代理ID IN (a, b, c, d, ……)
这个就是父子订单的查询吧。其实还有一只设计方式就是 在订单编号或者id上处理:父亲是 001(三位),儿子(001),孙子(001),后边的n位是就自己定义了。这样 父亲1的都是 001开头的,儿子1的肯定都是 001001开头的,孙子1的类似,这样你想查询出某个代理的下级下下级,就直接 like就行了 ,比如 like '001001%' 就肯定是 父亲1的儿子1的下级了
如果级数固定的话,订单表加冗余字段,把三级的id都存上(agent0_id、agent1_id、agent2_id),查询就可以直接根据当前等级和代理id查询了。
只要做过商城系统就知道,无限层级也是单独一个字段ID就能搞定的事,每个会员里多一个parent_id 的字段,parent_id = 上级ID,之后通过循环以此为太阳线抓取全部ID出来就是了,根本不用搞得那么复杂
order表外 加order_index 索引表 所有维度铺平 想加啥字段啥字段,专门为了查询, 维护好order order_index一致性就好
固定3级,直接查询3次就可以了
// User用户模型 // 儿子 public function sons() { return $this->hasMany(User::class, 'parent_id'); } // 孙子 public function getGrandsonsAttribute() { $sons = $this->sons()->pluck('id')->toArray(); return $this->query()->whereIn('parent_id', $sons)->pluck('id')->toArray(); } ...... // 业务Controller $user = User::query()->first(); // 一级代理的,查看自己以及下级 $orders = Order::query()->whereIn('user_id', array_merge($user->sons, [$user->id])); // 平台的,查看自己以及下两级 $orders = Order::query()->whereIn('user_id', array_merge($user->sons, $user->grandsons, [$user->id]));
你已经知道两种做法了。就是冗余一种,不冗余一种。
我推荐第3种,建一个order_append 表,id,order_id, order_key, order_value 这几个字段。
然后,order_key 分别等于agent0_id、agent1_id、agent2_id,甚至再多几层都没关系。
这样的话,order表会比较干净,查询也方便,兼顾到方方面面。
特别的,order表经常有不同类型的 订单,于是字段也会有差异,这种表就够灵活。
还有,我尽量不用like的。
作为订单的数据特性来讲,必须快照存储 平台 二级代理 三级代理 的 id。
因为平台、二级和三级代理的结构和数据存续可能会发生变化,但订单必须快照这些信息才能让查询不会出问题。
我要举报该,理由是:
中间关联表?es分词?
什么都es 。 我建议中间表搞定。
冗余字段吧,我看到别人一个表100个字段都有
订单量不大的话表结构
这样行不:
代理表 (ID,父ID,代理名称)和订单表 (ID,代理ID,……)
查订单时,先从代理表中,查出当前和所有下属代理,然后再到订单表中查找?
前者可通过
CTE实现,或者手动查出后,WHERE 代理ID IN (a, b, c, d, ……)?这个就是父子订单的查询吧。其实还有一只设计方式就是 在订单编号或者id上处理:父亲是 001(三位),儿子(001),孙子(001),后边的n位是就自己定义了。这样 父亲1的都是 001开头的,儿子1的肯定都是 001001开头的,孙子1的类似,这样你想查询出某个代理的下级下下级,就直接 like就行了 ,比如 like '001001%' 就肯定是 父亲1的儿子1的下级了
如果级数固定的话,订单表加冗余字段,把三级的id都存上(agent0_id、agent1_id、agent2_id),查询就可以直接根据当前等级和代理id查询了。
只要做过商城系统就知道,无限层级也是单独一个字段ID就能搞定的事,每个会员里多一个parent_id 的字段,parent_id = 上级ID,之后通过循环以此为太阳线抓取全部ID出来就是了,根本不用搞得那么复杂
order表外 加order_index 索引表 所有维度铺平 想加啥字段啥字段,专门为了查询, 维护好order order_index一致性就好
固定3级,直接查询3次就可以了
你已经知道两种做法了。就是冗余一种,不冗余一种。
我推荐第3种,建一个order_append 表,id,order_id, order_key, order_value 这几个字段。
然后,order_key 分别等于
agent0_id、agent1_id、agent2_id,甚至再多几层都没关系。
这样的话,order表会比较干净,查询也方便,兼顾到方方面面。
特别的,order表经常有不同类型的 订单,于是字段也会有差异,这种表就够灵活。
还有,我尽量不用like的。
作为订单的数据特性来讲,必须快照存储 平台 二级代理 三级代理 的 id。
因为平台、二级和三级代理的结构和数据存续可能会发生变化,但订单必须快照这些信息才能让查询不会出问题。