1
zieglar 2014-12-04 10:21:01 +08:00
不是mysql表的问题,一张会员表,纪录会员及推荐人,另外一张表记录各级推荐的阶梯返利
|
2
kisshere 2014-12-04 10:24:14 +08:00 via Android
搞传销,鉴定完毕,不过粗略想了想,这个跟MySQL没关系吧,业务逻辑就能实现啊,推广链接附带一个小尾巴,以php为例,把父ID,祖先ID(如果存在)用的数组serialize再可逆式加密(参考discuz加密)后生成这个小尾巴,php在GET后count一下array从而判断存在多少层父ID,然后该乘以8%还是2%自己添加就行了
|
3
mkeith 2014-12-04 10:35:01 +08:00
用户ID,上家ID
然后依次查找用户的上家,上家的上家,直至上家没有上家未知 |
4
blakefan OP 传销不传销不知道,但是项目是公司接的,咱们只负责做啊
|
5
xia0chun 2014-12-04 10:42:39 +08:00
不知道这样能不能满足你的要求,计算的时候分别乘以该级别的折扣即可 |
6
sampeng 2014-12-04 10:54:46 +08:00
见好友关系设计思路
|
7
blakefan OP 小猿跪谢啊
|
8
feiyuanqiu 2014-12-04 13:08:31 +08:00
@xia0chun 我觉得表里面存一个直接推荐人就行了
要考虑到以后需求会变,如果要求支持D推荐E那不是还要改表结构? 这个问题其实就是一个树状结构。我之前在公司做过仓库覆盖地区跟这个差不多。每条数据就只需要一个标识上级ID的字段就行了: 1、给定一个用户ID,要获取所有有关系的推荐人,只需要根据当前需要获取的推荐人数量,left join 几次这个表就行 2、如果要展示所有的推荐关系,可以把表内容全拿出来,PHP可以通过 [引用&] 操作一次遍历就把整个层级关系构建出来 |
9
jy02201949 2014-12-04 13:15:21 +08:00
ID 跟SUPERID, 再加个层级的字段1、2、3、4之类的,其实没有也没关系根据ID跟SUPERID我觉得就够了
|
10
stiekel 2014-12-04 13:53:41 +08:00
这个应该还好吧,一张用户表,一张各级奖励的具体数字表就行了。
用户表里,有个字段是标明推荐人的。 当要统计A的奖励数时,先看哪些人的推荐人是A——可以找到B,再看哪些人的推荐人是B——可以找到C,最后再找哪些人的推荐人是C——于是找到D。 再将各级的数量,与奖励表进行对应。 主要逻辑写到代码里,如果想逻辑写到MySQL,那就得用存过了。 |
11
xia0chun 2014-12-04 13:58:07 +08:00
|
12
zakokun 2014-12-04 14:16:49 +08:00
一张用户表就可以了. level 记录这个人在推荐链上的层级.
|