Storing expirable credits in database? - mysql

Question

It is easy to store user credit with an extra col in the user table, e.g. user_credits, now an extra requirement
for each credit added to the user_credits col, it will auto expire one year after if not being consumed.
Definitely I need an extra table for storing expiring information, e.g.
[table credits_history]
user_id
credits
used
created_at
So, when consuming credits, I need to
check if the user_credits is enough to consume
loop all credits_history table for the user's credit which used = 0 AND now - created_at < 1yr, and set used to 1
update the user_credits
Finally I need to set a daily cron job to update user_credits by looking at the created_at
Are the above approach reasonable? Or any standard way to handle the above requirements?

Answer 1

Don't store things that you can compute unless it's too expensive to calculate. Assuming that the number of rows in credits_history per user is not too high, you can structure your queries in such a way as to check the sum of available credits:
SELECT SUM(credits-consumed) -- see more about "consumed" below
FROM credits_history
WHERE user_id=?
AND created_at >= DATE_SUB(NOW(),INTERVAL 1 YEAR)
A nice side benefit of this approach is that you no longer need a cron job to maintain user_credits.
Consuming credits becomes a little tricky: you need to add a column showing the portion of the credit that has been used. Here is an example to illustrate this point. Let's say a user added these credits in his history:
created_on credits consumed
---------- ------- --------
05/06/2014 50 0
07/12/2014 70 0
12/01/2014 40 0
If you run the query above, you would get a sum of 160.
Now he wants to consume 90 credits. Your code should query all eligible credit records, order them from oldest to newest, and use as much credits as needed to cover the desired amount (i.e. 90)
created_on credits consumed
---------- ------- --------
05/06/2014 50 50
07/12/2014 70 40
12/01/2014 40 0
Now the query above would get a sum of 70.

Answer 2

No I don't think this is a normal approach. Normally you would have a table like user_credits which can have multiple rows for each user, each such row has the REMAINING credit, and expiry date (I think I prefer expiry date rather than created_at, since you calculate it only once). But then you would have a Transactions table which lists credits/debits (positive/negative credits). Buying credits would create a transaction of that amount of credits being added. Using credits would create a transaction of that amount of credits being deducted. Expiring credits would just be another transaction of credits being deducted. Each transaction also updates the remaining credit in user_credits.
The only annoying thing is that to calculate a user's current credits you have to go to user_credits and add up all of that user's rows. Some people might track another value in the main user table to bypass it.
Expiring credits can be done through a cron job to tidy up that table. Although if you want to be stingy you could check the expiry date at the time of the transaction as well to make sure nobody sneaks through just before the cron job.

Answer 3

I would do it as follows
TABLE: USER (id,name,address,phone,etc)
TABLE: CREDIT_TYPE(id,description, expiration_policy, etc)
TABLE: USER_CREDIT(user_id, credit_type_id, activation_date, expiration_date)
A user has zero or many credits
Each credit has some sort of expiration policy, rules, etx
If the CURRENT_DATE > expiration_date, the credit is expired
The expiration date is set immediately based on the policy set forth on the credit_type
Would that work?