The website needs a functional module to invite friends. The process is as follows:
The user center generates an invitation link for each person (A), and then after the invitee (B) clicks to register, A's ID is inserted as a mark after B's registration field.
Currently, this can count the list of friends invited by each person, but there will be the following problems in the future:
When invitee B places an order for the first time, he will be rewarded with 10% of the points reward. If it is not the first time he places an order, he will not be rewarded
(This is what I think in my own stupid way. When every user places an order, he will be rewarded first. Determine whether there is a superior user A. If not, place the order directly. If there is a superior user A, judge again whether the order is placed for the first time, then add points to the superior, and simultaneously place an order for user B)
Then the problem is that my stupid method needs to judge the first order for every order placed by each user. I feel that this is too cumbersome and prone to problems. I wonder if the master has any optimization ideas
I think it can be done like this:
Friend relationship: You can create a separate table,
Friend relationship table
, which stores two fieldsuid
(user ID),contact_uid
(associated friend ID)Whether it is the first time to place an order and add points for recommending friends: You can add a field to the user related table whether you have placed an order (also mentioned above), the default is 0, which means you have not placed an order, every time you place an order This field will be queried first. If it is
1
, the normal order logic will be followed; if it is 0, it means that the order has never been placed, and then the logic you will use will be executed, that is, whether the user has recommenders, and increase points for the recommenders. Waiting for processingDon’t do this, it will affect performance.
Statistical points are calculated every morning.
You can propose a table. This table has id, B's id, C's id, and the field buystate. The value of buystate can be 1 or 0. 0 means it is not the first purchase, and 1 means it is the first purchase
Add a field directly, whether you have placed an order before, the default is 0. Anyway, the user's information will be obtained when placing an order. By the way, you can judge whether it is equal to 0 to know whether it is the first order. In terms of points, if you are worried about performance, you can consider saving them in redis and modifying the database at a fixed time.
I think the idea is okay
One thing to mention, the reward points should be after the order is completed, not when the order is placed.
Just add a field to the user table to indicate the number of historical completed orders. If the demand changes later, it will be easy to return points for the first N times. And usually the process of placing an order or completing an order requires querying the user table, which is not complicated.