Question

我有一个应用程序，用户可以锁定某个商品，一旦他锁定它，他必须在2小时内拿起它。如果他在2小时内没有拿起它，那么该项目将被解锁并且用户失去1次锁定机会。用户最初有3次锁定机会，如果他在2个月内失去所有3次，那么他将被禁止2个月。现在我为此准备了一个模式，但我觉得它不是最佳的。架构看起来像这样

user table
--locking_chances_left              //initially 3
--first_chance_miss_date            //date on which the user loses its first locking chance
--second_chance_miss_date           //date on which the user loses its second locking chance
--banned                            // boolean field to indicate whether the user is banned

locked_items table
--item_no
--user_id
--locking_time

banned_users table
--user_id
--ban_date                          //date on which the user is banned i.e lost the last chance

现在我有一个事件计划每分钟运行，以查看locked_items表中的任何项目是否已被锁定超过2小时，如果找到任何项目，则将其从此表中删除，从而解锁item，然后从locking_chances_left表中将users减少1。现在我必须跟踪用户是否在2个月内失去所有机会来禁止他。所以我保留first_chance_miss_date来保持他的机会从3减少到2和second_chance_miss_date的日期，以保持他的机会从2减少到1的日期。我after update trigger { {1}}表，用于检查users的值何时更改，并相应地更新locking_chances_left和first_chance_miss_date。有没有使用second_chance_miss_date这两个字段并只使用一个字段的更好方法。谢谢你承担这个

Answer 1

我可能会在“user_missed_date”表中使用user_id和missed_date作为字段，然后

select user_id, count(*) as misses from user_missed_date where date>[last two months] group by user_id

或者将其用作子查询的基础。

你可能想要user_id，missed_date和missed_date上的索引，user_id

Answer 2

我不认为这是一个更好的解决方案，但我会把它扔出去：

您可以拥有一个lock_events表，而不是locked_items。每次项目被锁定时，它都会进入事件表。如果物品被拾取，您可以删除它，或者您可以添加一个额外的事件，说它已被拾取。如果您选择超过2小时的项目，则会获得已过期锁定项目的列表。

这样您就可以获得系统中所有事件的历史记录。计算chances_left很简单，也很容易看出用户是否在2个月内烧掉了所有机会。你最终在这里做了更多的CPU周期，但你也得到了你网站上所有交易的一个很好的记录！

更好的数据库架构

2 个答案: