我使用令牌来记录用户可以发送的邮件数量。 1 Message = 1 Token
。目前我只是从整体价值中减去价值来检查用户是否有剩余的令牌并且工作正常。
我试图将其更改为有效,以便显示哪个捆绑包处于活动状态,因此我正在寻找一些帮助,以检查用户是否在活动中没有足够的令牌捆绑更改到coming_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
每次发送邮件时是否应该检查数据库并更新数据库以一次减去1个令牌,然后当remaining_value
点击0
将active_bundle更改为非活动状态并将coming_bundle更改为活动状态时?
我想就此提出一些建议,谢谢先进。
答案 0 :(得分:1)
如果 您的数据模型,那么我将获取所有活动&即将推出的捆绑包然后在php中执行逻辑,例如减去剩余的令牌,更改状态等,然后将它们更新为交易。
如果您对数据的结构方式很灵活,我宁愿拥有某种事务日志,我可以从中读取每个操作,即是否添加了一个包,或者是否使用了带有时间戳的令牌。例如:
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)
而不是奇怪的搜索活动/即将推出的捆绑包。显然,根据您的需要,这可能或多或少都很精细。
这不考虑您的实际域名!有更多的方法各有其缺点。例如,由于用户数量和活动增加,我的方法可能会遇到问题,因为用户数量和活动增加,尽管这种方法很不可能(我已经看到mysql在类似的日志表中有几百万条记录表现良好)。重要的部分是:您应该找出对您的用例重要的内容并围绕要求构建解决方案。
答案 1 :(得分:0)
我会做的是,我会一次减去一个,不仅更安全,而且更容易。