消息提醒设计

[hhh798]

场景是这样的：每当有人给我的文章点赞、评论、关注我的时候，我就会收到消息提醒，

我是这样做的：我建了一个消息表，存储所有的消息记录，每个点赞、评论、关注都生成一条记录。

但是如果用户点赞或了我，数据库生成了记录，过会又取消了，此时记录已经生成了，等用户登录 APP 时，所以仍然会收到提醒。。

这种取消就不收到提醒，应该怎么做呢？

[hhh798]

@Vtwoguest 接下来就前台请求就查表把消息记录返回
@liuzhaowei55 什么事件主体，消息记录里有发送人、接收人了啊，消息记录里也加了是否已读标志、是否删除标志

[Vegetable]

来换一个顺序，点赞-通知-收到通知-取消点赞。这种情况下，用户已经读到了通知了，系统如果把通知删了，用户会很迷惑，所以唯一能做的就是再发一次取消点赞的通知（没见过谁家做这个功能...）。

这样很简单就可以意识到，通知是不可以删除的，不必特殊处理。

[YUyu101]

点赞应该是变动了 userpost 表，评论是变动了 comment 表，这些记录变动想放同一张表的话就要记录表名、主键、变动类型、变动字段，这样缺点是没有外键，每张表有各自的历史记录表的话可以用外键，但表会很多。这样之后再来一张或几张消息表对应这些历史记录、消息发送对象、已读未读，因为同一个变动可能要通知多个人，消息插入是被动的可以防止死用户占空间，在每次对象上线时开始根据上次上线时间后的变动遍历统计一遍，有取消的删除的可以这时候不加入消息表，历史记录表还是有的，统计完一起插入更新下用户登录时间。怕用户消息太多可以在统计时合并掉，反正消息只是一条消息，记录表里全都有。

[hst001]

这个时候对用户来说，报好不报坏未必不是好事

[hhh798]

现在消息表结构是这样的
id from_user to_user target_id type read status
自增 id 发送人 接收人 评论 id 或文章 id 消息类型 是否已读 是否取消

基本可以满足吧，点赞取消则根据 target_id 修改 status，关注取消则根据 from_user 修改 status
@Vegetable @YUyu101 我现在没做实时推送消息，就登录后请求一下后台，看有没有未读消息