GitHub 通知系统的设计猜想

notifications 数据表里有类似的两个字段：

type - 通知类型，如：issues、pull 等
type_id - 通知类型对应的 ID

当用户访问时：

https://github.com/summerblue/laravel5-che...

在入口里做这样的逻辑：

• 查看当前用户的 unread_notification_count 是否大于 0，否的话继续；
• 大于 0 的话，检查 notifications 表是否存在 type = pull 并且 type_id=11，不存在继续；
• 存在的话，删除此条数据，并把 unread_notification_count 减 1 ；

非常直接的逻辑，大家有没有更好的设计？

@Summer 如果增加一个通知表，那么还得关联上对应的pull request表，issues表，因为在获取通知列表的时候要有标题，作者信息，最后回复人信息。而且每次访问一个pull request详情页都去判断这个地址是不是在用户的未读通知表中，性能太浪费了吧，大部分时候都不在通知表里面。

还要维护用户表中的未读通知数和通知表中记录数的一致性，通知表会有频繁的查询删除操作，而且很有可能通知列表页是只显示最近n条未读通知的，用mysql也不好限制通知表中的记录数。

其实我就是想问一下这种情况用redis存通知可不可以，感觉挺麻烦的。