消息提醒设计

取消就删掉相应的未读提醒？

@ysoserious 无法知道是哪一条

@nioncodotcom 重新设计消息表或者提醒机制，找不到目标，无法撤回也不能拦截

@ysoserious 不知道行业内常用做法是咋样的

再发一条”某用户又取消了对你的点赞！“『皮』

取消可以不通知，不用管这个状态。如果前面用户看到关注的消息，点击进去发现粉丝已经取消了，这个也不是什么大问题，至少表示曾经粉过 up 主。

掉粉、粉转路人，很多系统都是不通知主人的

不太理解，不知道谁点赞哪一条那提醒有什么用，用户会看到什么呢？

微信朋友圈删除评论提醒数字还在点进去什么都没有我是一直不能理解啊。

就和上面说的一样，就不取消通知呗，又没问题。，
点赞后取消掉，用户收到通知发现没有被点赞，肯定会知道是别人取消了，这个其实也是符合用户操作逻辑的

如果想真的在用户接收到推送前删除这条消息，那你就只能重新设计表结构了，这没办法的
如果实在没办对原本的表做更改，那你就只能在其他地方记录生成的数据记录的 id 了（如果你的表里连自增的 id 键都没的话，那真的还是建议重新设计表结构了），然后加上点赞用户，被点赞用户，时间之类的信息，取消点赞的时候从这个表反查到 id，然后你搞完就会发现，还不如重新设计表最简单

不知道消息表怎么设计的
我想了下 如下字段不能完成这个需求么：
id from to type article_id deleted_at
- 关注的消息 article_id 是为空的
- 每种类型的消息都有自己的 type
- 取消的时候就给 deleted_at 增加一个取消时间戳，默认为空,或者直接物理删除
这样在取消关注、点赞、删除评论的时候根据 to+article_id 应该能锁定到消息了

搞对列比较合适


至于你说用户取消了，没办法取消的，已经发送的，是取消不了的

在消息表里加一个逻辑删除字段，取消时置 1，下次用户登录时查消息表数据决定是否提醒。
不过现在 app 好像都要进行推送的吧？

那样的话只能在推送发出之前拦截了，没拦住的话用户打开 app 看到点赞消息出现又消失？

5 楼正解，取消了再发一条取消的消息才是正常操作。

@xuanbg 取消有消息，感觉有点傻
@nvkou 被点赞、被评论、被关注的人需要知道呀
@EscYezi 准备加一个逻辑删除字段了
@Immortal 就准备这么干了
@hakono 表重新设计了

很多 App 的逻辑都是关注有提醒，关注之后取消不提醒，点进去就会显示无
另外想问一下表存在记录后接下来的逻辑是如何设计的呢

如果按现在的消息表这样设计，在消息表里应该关联该消息的事件主体会好一点，不然以后这条消息就是孤岛了。
之前我也是这样设计的，不过后来就取消了消息表的设计，直接在事件主体上标注受影响人对于这条消息的已读未读删除，结构更简单了，毕竟也只是一个事件的通知，一般也就未读已读删除三个操作。

接着讨论，我们也有消息系统，晚上来看结论，优化我们的消息系统。

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

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

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

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

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

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

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