我很快就会提供一些基于网络的服务，而我正在开发订阅系统。用户每月支付（或可以提前支付几个月），但我提供不同的套餐。不同的软件包允许他们每天使用系统x分钟。
所以例如
套餐一让他们每天使用它2分钟 套餐2允许他们每天使用它5分钟 套餐3允许他们每天使用它10分钟
等等。这些都是每月一次。
我当前的方法会让我设置他们的包，以及他们的订阅何时结束。我想改变它，以便它们可以有多个包。
我的问题是：
他们买一包。他们使用它两天并决定他们想要升级到另一个包。他们买二包。现在他们有2个月（减去两天），但它将是第二包。基本上他们只需要额外一个月的套餐二包价格。
所以我的想法是这样的：
我可以单独存储每个事务，并在每个事务集中存储该程序包结束时以及它是哪个程序包。然后我可以SELECT `package` FROM `packages` WHERE `status`='active????' ORDER BY `package` DESC LIMIT 1;这将允许我选择他们的更高的包并给他们，直到那个变为非活动状态，然后恢复到较小的包。问题是此`status`='active'无法跟踪日期。我怎样才能正确地做到这一点？
答案 0 :(得分：0)
我曾与“每分钟付费”交易合作，这是一个恐怖故事。至少我提出的场景是因为客户端计时和服务器端可以是两个不同的世界（例如暂停加载的流视频与用户在日期差异确定的页面上的实际时间）。
这是我们如何处理它 - 除了打嗝补偿的平衡 - 用户购买分钟简单明了。如果他们升级，他们将根据他们购买时所设定的价格按比例退还未使用的会议记录。这样，如果在退款发生后向他们收取费用，您就不会失败。 退款不是字面交易。它转储到与用户相关的余额中，然后按比例退款降低升级价格。将付费的分钟数返回到零 - 在添加新的升级分钟之前。
系统中的漏洞通过将每个“单位”减少到最低形式并使经济性偏离该数量来解决。所以没有“套餐”可言。根据用户购买时间，用户和每分钟的成本只有几分钟。这样，如果您的费率发生变化，则不会影响可能提前预付年费的旧用户。
请注意，这是一个简化的例子。实际系统非常复杂。
对于您的方案，每日限制只是一个关系表，可以在单个加载的基础上存储日期和集合页面时间，但是您可以选择确定。不是一个试图积累的条目，而是您可以收集的个别条目，并尽可能地将它们加起来。当有人抱怨他们的计算机冻结并且他们失去了无法控制的分钟时，这将为您节省大量时间。 因此，当您的总和脚本根据当前限制检测到分钟已达到或超过时，它就会拒绝访问。
答案 1 :(得分：0)
你应该只有一个包裹。升级时，您应该减去新旧包中使用的分钟数。只是保留旧包是历史记录。