订阅包和存储

Question

我很快就会提供一些基于web的服务，我正在开发订阅系统。用户按月支付(也可以提前几个月支付)，但我提供了不同的套餐。不同的软件包允许他们每天使用系统x分钟。

举个例子

套餐1让他们每天使用2分钟

套餐2让他们每天使用5分钟

套餐三让他们每天使用10分钟

以此类推。这些都是月度的。

我当前的方法将允许我设置他们的包以及他们的订阅何时结束。我想改变这一点，这样他们就可以有多个包了。

我的问题是：

他们买的是套餐一。他们使用了两天，然后决定要升级到另一个包。他们买了第二个套餐。现在他们有两个月(减去两天)，但这将是第二个包。基本上，他们只是以套餐1的价格额外获得了套餐2的一个月。

所以我的想法是：

我可以单独存储每个事务，并在每个事务集中存储该包何时结束以及它是哪个包。然后我可以SELECT `package` FROM `packages` WHERE `status`='active????' ORDER BY `package` DESC LIMIT 1;，这将允许我选择他们的较高的包，并给他们，直到那个变成不活跃，然后恢复到较小的包。问题是这个`status`='active'没有记录日期。我该如何正确地做这件事呢？

Answer 1

我曾经处理过“按分钟付费”的交易，这是一个可怕的故事。至少我看到的场景是因为客户端计时和服务器端可以是两个不同的世界(比如暂停加载的流视频和用户在页面上的实际时间由日期差异确定)。

这就是我们如何处理它--抛开打呃补偿的平衡--用户简单明了地购买分钟。如果他们升级了，他们被退还未使用的分钟的比例，根据他们购买时设置的价格，在新的分钟收费后。这样一来，如果在退款发生后向他们收费有问题，你也不会损失。退款不是字面上的交易。它转储到与用户关联的余额中，然后通过按比例退款来降低升级价格。将付费分钟数恢复为零-然后添加新的升级分钟数。

系统中的漏洞通过将每个“单位”减少到其最低形式并以该数字为基础来解决。因此，没有什么“包”可言。只有与用户关联的分钟数和每分钟的费用取决于他们购买它们的时间。这样，即使您的费率发生变化，也不会影响可能提前几年预付的老用户。

请注意，这是一个简化的示例。实际的系统非常复杂。

对于您的场景，每日限制只是一个关系表，它以单个加载为基础存储日期和集合页面时间，无论您如何选择来确定它。不是试图累积的单个条目，而是您可以收集的尽可能小的单个条目，并尽可能地对其求和。当有人抱怨他们的电脑死机了，失去了他们无法控制的时间时，这将为你节省大量的时间。因此，当sum脚本根据当前限制检测到分钟数已达到或超过时，它将拒绝访问。

Answer 2

您应该只有一个包。升级时，您应该减去新旧包中使用的分钟数。只需保留旧包即可作为历史记录。