请问一下牛人，如果有这样一个需求该怎么样设计一张 mysql 表；

[blakefan]

请问一下牛人，如果有这样一个需求该怎么样设计一张mysql表；
1、A直接推荐B，可享受B所交会员费的8%;
2、B推荐C，A享受C所交会员费的2%，B享受C的8%；
3、C 推荐D，A享受D的1%，B享受D的2%，C享受D的8%；

[zieglar]

不是mysql表的问题，一张会员表，纪录会员及推荐人，另外一张表记录各级推荐的阶梯返利

[kisshere]

搞传销，鉴定完毕，不过粗略想了想，这个跟MySQL没关系吧，业务逻辑就能实现啊，推广链接附带一个小尾巴，以php为例，把父ID，祖先ID(如果存在)用的数组serialize再可逆式加密(参考discuz加密)后生成这个小尾巴，php在GET后count一下array从而判断存在多少层父ID，然后该乘以8%还是2%自己添加就行了

[mkeith]

用户ID,上家ID

然后依次查找用户的上家,上家的上家,直至上家没有上家未知

[blakefan]

传销不传销不知道，但是项目是公司接的，咱们只负责做啊

[xia0chun]

不知道这样能不能满足你的要求，计算的时候分别乘以该级别的折扣即可

[sampeng]

见好友关系设计思路

[blakefan]

小猿跪谢啊

[feiyuanqiu]

@xia0chun 我觉得表里面存一个直接推荐人就行了
要考虑到以后需求会变，如果要求支持D推荐E那不是还要改表结构？

这个问题其实就是一个树状结构。我之前在公司做过仓库覆盖地区跟这个差不多。每条数据就只需要一个标识上级ID的字段就行了：

1、给定一个用户ID，要获取所有有关系的推荐人，只需要根据当前需要获取的推荐人数量，left join 几次这个表就行

2、如果要展示所有的推荐关系，可以把表内容全拿出来，PHP可以通过 [引用&] 操作一次遍历就把整个层级关系构建出来

[jy02201949]

ID 跟SUPERID， 再加个层级的字段1、2、3、4之类的，其实没有也没关系根据ID跟SUPERID我觉得就够了

[stiekel]

这个应该还好吧，一张用户表，一张各级奖励的具体数字表就行了。
用户表里，有个字段是标明推荐人的。
当要统计A的奖励数时，先看哪些人的推荐人是A——可以找到B，再看哪些人的推荐人是B——可以找到C，最后再找哪些人的推荐人是C——于是找到D。
再将各级的数量，与奖励表进行对应。

主要逻辑写到代码里，如果想逻辑写到MySQL，那就得用存过了。

[xia0chun]

@feiyuanqiu
@stiekel
嗯嗯，学习了，应该是我想简单了，我也是刚刚学习数据库 :)

[zakokun]

一张用户表就可以了. level 记录这个人在推荐链上的层级.

[stiekel]

@zakokun 这样做基本没办法扩展，而且，无法进行反向对应，像D就无法知道是谁推荐了自己，C也不知道自己推荐了哪些人。