跟踪用户代币/硬币的策略

Question

我正在开发一个网络应用程序，用户每月购买代币/代币 - 这意味着代币在月底到期（例如，3 美元将在一个月内获得 5 个代币）。在存储和跟踪每个用户令牌时要采取什么策略，我有点困惑。

在一个两部分的问题中：

1) 由于用户通常可以在一个月的任何阶段购买代币，因此月份是否定义为“30”天，或者它们是否映射到日历月的天数？ （例如：如果在 3 月购买代币，它们会持续 31 天，但如果在 5 月购买，它们会持续 30 天吗？）

2) 问题的第二部分是如何跟踪这些令牌？如果用户支付一年的订阅费用（每月 5 个代币，为期 12 个月），但也被允许在一年中购买更多代币（6 月用户想要 10 个代币），我如何才能真正跟踪有多少每个月都买过代币吗？

我有一些实现想法，但没有一个看起来“正确”。希望有人可能已经解决了类似的问题，或者可以向我指出任何相关文献。

提前致谢。

Answer 1

由于用户通常可以在一个月的任何阶段购买代币， 是定义为“30”天的月份，或者它们是否映射到 日历月？ （例如：如果代币是在 3 月份购买的，那么 它们持续 31 天，但如果在 5 月购买，它们持续 30 天？）

总是 1 个完整月。

为什么？因为你对你的用户很好；）

由于日期方法的简单性，我会选择整月。并且更容易跟踪成员。 对于喜欢在 2 月底购买最多代币的人来说，31 天是一个更好的选择。 例如，1 月 31 日的购买将在 3 月 3 日到期，而不是 2 月 28 日。

当然您可以自己决定，但这是最合理的选择，也可以确保您减少与客户的麻烦。

问题的第二部分是如何跟踪这些令牌？如果一个 用户支付一年的订阅费（每月 5 个令牌，共 12 个月），但也可以在期间购买更多代币 年（六月用户想要 10 个代币），我该如何实际保留 跟踪每个月购买了多少代币？

为每个代币购买创建一个表格，其中包含购买时间和日期以及代币数量。

TokenPurchaseNumber | UserId | TokenCount | PurchaseDateTime| ExpireDateTime
---------------------------------------------------------------------
10001               | 1      | 200        | Jan 20          | Feb 20
10002               | 1      | 100        | Jan 24          | Feb 24
10002               | 2      | 300        | Jan 24          | Feb 24
10003               | 1      | 20         | Jan 25          | Feb 25
10004               | 1      | 40         | Jan 29          | Feb 29

通过这种方式，您可以使用唯一的购买编号对所有购买进行良好存档，并且可以为用户生成购买历史记录。

您可以考虑不使用 ExpireDateTime 列，因为您只需将购买代币的日期 + 31 天与今天进行比较。

现在如何计算用户拥有的令牌总数似乎是下一个问题。

两个选项，第一个将有更好的购买历史和存档。

选项 1：

这相当简单，每次用户购买代币时，您都会在上表中创建一行，并将其加到他自己的用户表列tokens中保存的总金额中。

每次用户登录（或您想要的任何其他选择的时间）时，您都可以检查他们的总令牌，例如 165。

现在是 2 月 21 日，因此您可以查看他在 1 月 21 日之后购买的所有代币。我们把它们加起来，我们看到用户只能拥有 100+20+40=160 的可能数量的有效令牌。所以我们移除了他的 5 个代币并向他发送了一条消息，他在 1 月 20 日购买的 #10001 中的 5 个代币已过期。

第二个选项：

当用户使用它们时，只需从最旧的购买中移除代币。当到期日期到期时，删除整个购买行，有效地删除该购买的剩余令牌。

Answer 2

1) 这取决于您。我认为拥有代币持续 30 天或正好 1 个月之间没有太大区别，但在我看来，持续 30 天更好——我宁愿知道无论何时我购买的 5 美元都值得做他们。无论您决定什么，请确保清楚地向用户说明。

2) 由于每组令牌可以有不同的“到期”日期，因此您必须将它们分别存储在后端数据库中。当用户使用令牌时，减少剩余令牌的数量，直到达到零。

TokenGroupId | UserId | TotalTokens | RemainingTokens | Active | Expires
------------------------------------------------------------------------
6789         | 1234   | 5           | 2               | Mar 1  | Mar 31
6790         | 1235   | 5           | 5               | Mar 13 | Apr 12

Answer 3

我必须实施一次这样的系统。我使用以下想法解决了。

您实际上并不想在数据库中存储用户的代币总数，而是存储每个购买操作以及购买的代币数量。

数据库结构如下所示：

- purchase_id
- user_id
- dollar_amount
- purchase_date
- expiration_date
- purchased_tokens
- remaining_tokens

这里的重点是您存储所购买代币的到期日期，例如，如果某些代币可能具有更重要的持续时间，例如促销操作。

存储的也是已购买代币的总数以及剩余代币的数量。由于我们不存储用户拥有的令牌总数，因此我们需要跟踪实际花费了哪些令牌，因此我们可以通过对尚未过期的remaining_tokens 求和来计算总数。

要选择要花费的代币，基本的想法是始终花费购买的最旧的代币，并在获得 0 个剩余代币时从下一次购买中取出。