2

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

在一个两部分的问题中：

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

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

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

提前致谢。

4

3 回答 3

4

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

总是 1 个完整月。

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

由于日期方法的简单性，我会选择整月。并且更容易跟踪成员。对于喜欢在 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 个代币已过期。

第二种选择：

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

于 2013-02-21T22:13:04.560 回答
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
于 2013-02-21T22:12:39.463 回答
0

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

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

数据库结构如下所示：

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

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

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

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

于 2013-02-21T22:20:08.377 回答