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

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

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

用户ID,上家ID

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

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

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

见好友关系设计思路

小猿跪谢啊

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

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

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

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

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

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

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

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

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

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