传销下线分布数量
我制作了我的第一个传销软件,我想我设法编写了如何从下线获取积分的代码,即使这是一个递归问题,我没有使用递归,如果这看起来更好,我可能会重构为递归版本。在我们的系统中,经销商的级别是通过银币的数量来衡量的,并且对于每件销售的产品,促销/奖金/分数/积分都会在线工作,因此如果鲍勃是爱丽丝的赞助商并且爱丽丝进行了购买,那么鲍勃将获得积分以该次购买的银币数量来衡量。我向我的用户类添加了一个业务功能:
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
现在要做的只是根据订单深度对白银进行百分比计算。 该代码实际上为订单下线输出了正确的结果,但我还没有对其进行广泛的测试,我想知道您是否认为该代码看起来很奇怪,以及我是否考虑到了所有内容,因为模型有些复杂/先进。用户类来自 webapp2,我可以使用子类,但我没有时间这样做,所以我只是将方法放入那里的用户类中,现在我可以从 Jinja2 调用它,如 {{user .this_month_non_manager_silver}}
递归可能是执行此操作的正确方法,但我的解决方案是否仍然可以,我可以继续并暂时保留此代码,或者您认为这是不可接受的?
感谢任何建设性的批评。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我在这里看到的主要问题是,您本质上是在尝试进行广度优先搜索(您查看经销商下方的所有用户,然后查看这些经销商下方的所有用户,等等),但是每个当 while 循环循环时,您只会查看最后一个经销商下面的用户。
如果我们将重要部分分解为类似 python 的内容,您会得到以下结果:
如您所见,访问第一组下线后经销商的值是用户下线中的最后一个经销商。然后,下次运行 for 循环时,您只需查看最后一个经销商的下线。
传统上,树遍历算法要么是递归的,要么是基于堆栈的循环。通常,您会根据内存限制选择其中之一。为了保持解决方案的迭代性,您需要重写上面的 python 代码,如下所示:
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:
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: