我正在开发一个网络应用程序，用户每月购买代币/硬币 - 意味着代币将在月底到期（例如，3美元将在一个月内获得5个代币）。关于存储和跟踪每个用户令牌的策略，我有点困惑。
分两部分提问：
1）由于用户通常可以在一个月的任何阶段购买代币，将月份定义为“30”天，还是映射到日历月的日期？ （例如：如果代币是在3月份购买的，它们会持续31天，但如果在5月购买它们会持续30天吗？）
2）问题的第二部分是如何跟踪这些令牌？如果用户支付一年的订阅费（每月5个令牌，为期12个月），但也允许在一年中购买更多令牌（6月用户想要10个令牌），我怎样才能真正跟踪多少令牌每个月都买了代币？
我有一些实施想法，但没有一个看起来“正确”。希望有人可能已经解决了类似的问题，或者可以指出任何相关的文献。
提前致谢。
答案 0 :(得分：4)
由于用户通常可以在本月的任何阶段购买代币， 被定义为“30”天的月份，或者它们是否映射到a的日期 日历月？ （例如：如果在3月份购买代币，那么 他们持续31天，但如果在五月购买，他们可以持续30天？）
总是整整一个月。
为什么呢？因为你对用户很好;）
由于日期方法简单，我会选择整整一个月。更容易跟踪成员。 对于喜欢在2月底购买最多代币的人来说，31天是更好的选择。 例如，1月31日的购买将于3月3日到期，而不是2月28日。
当然，您可以自行决定，但这是最合理的选择，也可以确保您减少客户的麻烦。
问题的第二部分是如何跟踪这些令牌？如果一个 用户支付一年的订阅费（每月5个代币，12个 几个月）但也允许在购买过程中购买更多代币 这一年（6月用户想要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个令牌已经过期。
第二个选项：
只需在用户使用时从最早的购买中移除令牌即可。当到期日期到期时，删除整个采购行，有效地删除该购买的剩余代币。
答案 1 :(得分：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
答案 2 :(得分：0)
我必须实施一次这样的系统。我用以下的想法解决了。
您实际上不希望在数据库中存储用户的令牌总数，而是存储每个购买操作以及购买的令牌数量。
数据库结构如下所示：
- purchase_id
- user_id
- dollar_amount
- purchase_date
- expiration_date
- purchased_tokens
- remaining_tokens
重要的一点是，您存储所购买代币的到期日期，例如，某些代币可能具有更重要的持续时间，例如促销操作。
存储也是购买的令牌总数以及剩余令牌的数量。由于我们不存储用户拥有的令牌总数，因此我们需要跟踪实际花费的令牌，因此我们可以通过将尚未过期的remaining_tokens相加来计算总数。
要选择要花费哪些代币，我们的想法基本上就是始终花费购买的最旧代币，并在下次购买时将其带走，一旦获得剩余的代币，就可以使用它们。