我认为对于用户通知来说,对数据库进行反规范化是必要的。例如,当标记一个帖子(应该被用户考虑)时,我们添加一个flag ENUM('yes', 'no')
列(或状态列)。通过计算user_id='XX' AND flag='yes'
WHERE子句,可以找到一个用户的标记事件。
这种规范化结构很好;但如果我们有不同类型的通知,例如帖子、评论和照片的标记……这意味着当用户只访问他的个人资料页面时,我们需要计数多个表格。 对于像StackExchange这样的跨项目来说,这更加严重,因为我们得到来自不同站点的通知。
我认为反规范化可以帮助将通知列添加到用户表中,如下所示:
post_flags tinyint(3),
comment_flags tinyint(3),
photo_flags tinyint(3),
在这种情况下,我们需要运行一个额外的写查询来更新每个相应操作上的用户标志列。例如,当标记帖子时:
UPDATE users SET post_flags=post_flags+1 WHERE user_id='XX'
。我的担心是确保后面的查询执行以避免该数字与标记帖子数量不匹配; 但我认为可以通过TRANSACTION
来保证。这样,我们可以通过一次查询获取所有频繁访问的个人资料页面上的所有通知。
我走对了吗?还是有其他诡计常用于此目的?
tinyint(3)
中存储什么?难道不会有多个条目吗? - Karoly Horvath