在用户表中添加额外的col，很容易存储用户信用，例如user_credits，现在是一项额外要求
user_credits col的每个赠送金额，如果没有被消费，它将在一年后自动过期。我当然需要一个额外的表来存储过期信息，例如
[table credits_history]
user_id
credits
used
created_at
所以，在消费学分时，我需要
user_credits是否足以消费credits_history用户信用的所有used = 0 AND now - created_at < 1yr表格，并设置used to 1 user_credits 最后，我需要设置每日cron作业，通过查看user_credits
created_at
上述方法是否合理？或者是处理上述要求的任何标准方式？
答案 0 :(得分：2)
不要存储您可以计算的东西，除非计算成本太高。假设每个用户credits_history中的行数不是太高，您可以构建查询，以便检查可用信用额的总和：
SELECT SUM(credits-consumed) -- see more about "consumed" below
FROM credits_history
WHERE user_id=?
AND created_at >= DATE_SUB(NOW(),INTERVAL 1 YEAR)
这种方法的另一个好处是你不再需要一个cron作业来维护user_credits。
消费信用变得有点棘手：您需要添加一个列，显示已使用的信用部分。这是一个说明这一点的例子。假设用户在其历史记录中添加了这些信用：
created_on credits consumed
---------- ------- --------
05/06/2014 50 0
07/12/2014 70 0
12/01/2014 40 0
如果你运行上面的查询，你将得到160的总和。
现在他想要消耗90个学分。您的代码应查询所有符合条件的信用记录，从最旧到最新订购它们，并根据需要使用尽可能多的信用额度来覆盖所需的金额（即90）
created_on credits consumed
---------- ------- --------
05/06/2014 50 50
07/12/2014 70 40
12/01/2014 40 0
现在上面的查询得到70的总和。
答案 1 :(得分：0)
我会这样做
表：USER (id,name,address,phone,etc)
表：CREDIT_TYPE(id,description, expiration_policy, etc)
表：USER_CREDIT(user_id, credit_type_id, activation_date, expiration_date)
根据credit_type
中规定的政策立即设置到期日期那会有用吗？
答案 2 :(得分：0)
不，我不认为这是一种正常的做法。通常你会有一个像user_credits这样的表，每个用户可以有多行，每一行都有REMAINING信用和有效期（我想我更喜欢有效期而不是created_at，因为你只计算一次）。但是你会有一个交易表，列出信用/借方（正/负信用）。购买积分将创建一个额外信用额度的交易。使用信用将创建扣除该信用额度的交易。到期信用将只是被扣除的信用额度的另一个交易。每笔交易还会更新user_credits中的剩余信用。 唯一令人烦恼的是，要计算用户的当前信用，您必须转到user_credits并将所有该用户的行相加。有些人可能会跟踪主用户表中的另一个值以绕过它。
到期学分可以通过cron作业完成整理该表。虽然如果你想要吝啬，你也可以在交易时查看到期日，以确保没有人在cron工作之前偷偷摸摸。