我使用令牌表示用户可以发送多少条消息(1条消息需要1个令牌)。目前，我只是让它从总体值中减去值，以检查用户是否有令牌剩余，这工作得很好。
我试图改变它，以便它显示哪个bundle是活动的，所以我需要检查用户是否没有足够的令牌留在活动bundle更改到upcoming_bundle。
的例子:
已存储用户数据:
Table Name: Tokens
第一张唱片
id: 1
user_id: 5
bundle_type: small
value: 10
value_remaining: 4
state: active_bundle
二次记录
id: 2
user_id: 5
bundle_type: large
value: 100
value_remaining: 100
state: Upcoming_bundle
- 用户发送10条消息(10个令牌)
- 第一个记录中只剩下4个令牌。使用剩下的4个代币然后离开6标记
- 然后从现在活动的第二个记录中减去6个令牌，这样将留下94个剩余的令牌。
我是否应该在每次发送消息时检查数据库并更新数据库以每次减去1个令牌，然后当remaining_value击中0时将active_bundle更改为非活动并且upcoming_bundle更改为活动?
如果这个是你的数据模型，那么我将获取所有活动&然后在php中执行逻辑，例如减去剩余的令牌，更改状态等，然后将它们作为事务更新。
如果你对数据的结构是灵活的，我宁愿有某种事务日志，从中我可以读取每个动作，即是否添加了一个bundle或一个令牌与时间戳一起使用。例如:
id | user | change | comment | timestamp
1 | 1 | 10 | bought small bundle | 2016-09-06 09:30:00
2 | 1 | -1 | sent message | 2016-09-06 10:56:00
3 | 2 | -3 | sent multi-message | 2016-09-06 10:57:00
其中id是事务id, user是用户id, change是添加令牌(通过添加一个包)或使用令牌(通过发送一个或多个消息)的数量，comment是描述操作的消息。当你想知道还有多少令牌时，你可以搜索该用户并检查他们的SUM(change)，而不是奇怪地搜索活动/即将到来的捆绑包。显然，这可以根据您的需要或多或少地详细说明。
这没有考虑到您的实际域名!还有更多的方法，每种方法都有其缺点。例如，当transaction_log-table由于用户数量和活动的增加而变得很大时，我的方法可能会出现问题，尽管这是非常不可能的(我已经看到mysql在类似的日志表中有几百万条记录时表现良好)。重要的部分是:您应该弄清楚什么对您的用例是重要的，并围绕需求构建解决方案
我要做的是，每次减去一个，这不仅更安全，而且更容易。