讨论数量:
notifications
数据表里有类似的两个字段:
type - 通知类型,如:issues、pull 等
type_id - 通知类型对应的 ID
当用户访问时:
在入口里做这样的逻辑:
- 查看当前用户的
unread_notification_count
是否大于 0,否的话继续; - 大于 0 的话,检查 notifications 表是否存在 type = pull 并且 type_id=11,不存在继续;
- 存在的话,删除此条数据,并把
unread_notification_count
减 1 ;
非常直接的逻辑,大家有没有更好的设计?
@Summer 如果增加一个通知表,那么还得关联上对应的pull request表,issues表,因为在获取通知列表的时候要有标题,作者信息,最后回复人信息。而且每次访问一个pull request详情页都去判断这个地址是不是在用户的未读通知表中,性能太浪费了吧,大部分时候都不在通知表里面。
还要维护用户表中的未读通知数和通知表中记录数的一致性,通知表会有频繁的查询删除操作,而且很有可能通知列表页是只显示最近n条未读通知的,用mysql也不好限制通知表中的记录数。
其实我就是想问一下这种情况用redis存通知可不可以,感觉挺麻烦的。
推荐文章: