传销下线分布数量 [英] MLM downline distribution count

查看:240
本文介绍了传销下线分布数量的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我制作了我的第一个MLM软件,我认为我设法编写了如何从下线获得点数的方法,尽管这是一个递归问题,我没有使用递归方法,如果这看起来更好,我可能会重构递归版本。在我们的系统中,分销商的水平是衡量我的银牌数和每个销售的产品的促销/奖金/分数/积分上线,所以如果鲍勃是爱丽丝的赞助商,爱丽丝购买,那么鲍勃将获得积分以购买的银饰数量来衡量。我为我的用户类添加了一个商业功能:

  def this_month_non_manager_silver(self):
silver = 0
today = date.today()
timeline = date(today.year,today.month,1)
downline = User.query(User.sponsor
== self._key)。 fetch()
distributor = self
而distributor.has_downline():
downline = User.query(User.sponsor == distributor.key).fetch()
for person在下线:
orders = model.Order.all()。filter('buyer_id =',person.key.id())。filter('created>',timeline).filter('status =' ,'PAID')。fetch(999999)
为订单中的订单:
为idx,枚举中的项目(order.items):
purchase = model.Item.get_by_id(long .id()))
amount = int(order.amounts [idx])
silver = silver +金额* purchase.silver / 1000.000
分销商=人
回报银

现在可以做的只是银的一个%到订单的深度。
代码实际上为下订单输出正确的结果,但我还没有广泛测试它,我不知道你是否认为代码看起来很奇怪,以及是否因为模型有点复杂/先进而想到了所有的东西。用户类是从webapp2,我可以使用一个子类,但我没有时间这样做,所以我只是把方法放在那里的用户类,现在我可以从Jinja2调用它,如 {{user.this_month_non_manager_silver}}



递归可能是正确的方法,但这并不是我的解决方案,我可以移动现在保留这些代码,或者您认为这是不可接受的吗?



感谢您提供任何建设性的批评。

解决方案

我在这里看到的主要问题是,你基本上试图做一个广度优先的搜索(你看所有在分销商下面的用户,然后看看这些分销商下面的所有用户等等),但每次while循环循环时,您只查看最后分销商下面的用户。



如果我们把重要的部分分解成一些python-ish,你会得到这个:

 经销商= self 
,而distributor.has_downline():
for distributor in distribution.downline:
distributor = person

正如您所看到的,第一套下线后的分销商价值是用户下线中的最后一个分销商。然后下一次运行for循环时,您只会查看最后一个分销商的下线。传统上,树行走算法是递归的或基于循环的一个堆栈。一般来说,您会根据内存限制选择其中一种。为了保持迭代的解决方案,您需要像这样重写上面的python-ish代码:

  downlinestack = [] 
分销商=自己
downlinestack + =分销商。下线
下行线:
下线= downlinestack.pop()
下线人:
downlinestack.append (person.downline)


I make my first MLM software and I think I managed to code how to get the points from the downline even though it is a recursive problem I didn't use recursion and I might refactor to a recursive version if that seems better. With our system, the level of a distributor is measured i number of silvers and for each product that gets sold the promotion/bonus/score/points works upline so if Bob is the sponsor of Alice and Alice makes a purchase then Bob will get points measured in number of silvers for that purchase. I added a business function to my user class:

def this_month_non_manager_silver(self):
    silver = 0 
    today = date.today()
    timeline = date(today.year, today.month, 1) 
    downline = User.query(User.sponsor
            == self._key).fetch()
    distributor = self
    while distributor.has_downline():
        downline = User.query(User.sponsor == distributor.key).fetch()
        for person in downline:  
            orders = model.Order.all().filter('buyer_id =' , person.key.id()).filter('created >' , timeline).filter('status =', 'PAID').fetch(999999)
            for order in orders:
                for idx,item in enumerate(order.items):
                    purchase = model.Item.get_by_id(long(item.id()))
                    amount = int(order.amounts[idx])
                    silver = silver + amount*purchase.silver/1000.000 
            distributor = person
    return silver

What might be to do is now just a % on the silver according to the depth of the order. The code actually output the correct result for an order downline but I didn't yet test it extensively and I wonder if you think the code looks strange and if I have thought of everything since the models are somewhat complicated / advanced. The user class is from webapp2 and I could use a subclass but I didn't have time to do that so I just put in the method to the user class that's there and now I can call it from Jinja2 like {{user.this_month_non_manager_silver}}

Recursion might to be right way to do this but isn't my solution still OK and I can move on and keep this code for now or do you think it is not acceptable?

Thanks for any constructive criticism.

解决方案

The main problem I see here is that you're essentially trying to do a breadth-first search (you look at all the users who are below the distributor, then look at all of the users below those distributors, etc etc), but each time the while loop loops you're only looking at the users below the last distributor.

If we break down the important parts into something python-ish, you get this:

distributor=self
while distributor.has_downline():
    for person in distributor.downline:
        distributor = person

As you can see, the value of distributor after the first set of downlines are accessed is the last distributor in the user's downline. Then the next time the for loop is run, you're only looking at the last distributor's downline.

Traditionally a tree-walking algorithm is either recursive or loop-based with a stack. Generally you will choose one or the other based on memory constraints. To keep the solution iterative, you'd need to rewrite the above python-ish code like this:

downlinestack = []
distributor=self
downlinestack += distributor.downline
while downlinestack:
    downline = downlinestack.pop()
    for person in downline:
        downlinestack.append(person.downline)

这篇关于传销下线分布数量的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆