这是一个创建于 1855 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景是这样的：每当有人给我的文章点赞、评论、关注我的时候，我就会收到消息提醒，
我是这样做的：我建了一个消息表，存储所有的消息记录，每个点赞、评论、关注都生成一条记录。
但是如果用户点赞或了我，数据库生成了记录，过会又取消了，此时记录已经生成了，等用户登录 APP 时，所以仍然会收到提醒。。
这种取消就不收到提醒，应该怎么做呢？
 |
1
ysoserious 2019-10-21 23:15:25 +08:00 via Android
取消就删掉相应的未读提醒？
|
 |
2
hhh798 OP @ysoserious 无法知道是哪一条
|
|
3
ysoserious 2019-10-21 23:30:43 +08:00 via Android
@nioncodotcom 重新设计消息表或者提醒机制，找不到目标，无法撤回也不能拦截
|
|
4
hhh798 OP @ysoserious 不知道行业内常用做法是咋样的
|
 |
5
bukip 2019-10-21 23:58:56 +08:00
再发一条”某用户又取消了对你的点赞！“『皮』
|
 |
6
rogwan 2019-10-22 00:40:35 +08:00 via iPhone
取消可以不通知，不用管这个状态。如果前面用户看到关注的消息，点击进去发现粉丝已经取消了，这个也不是什么大问题，至少表示曾经粉过 up 主。
|
|
7
rogwan 2019-10-22 00:41:19 +08:00 via iPhone
掉粉、粉转路人，很多系统都是不通知主人的
|
 |
8
lzxgh621 2019-10-22 01:14:31 +08:00
不太理解，不知道谁点赞哪一条那提醒有什么用，用户会看到什么呢？
|
|
9
lzxgh621 2019-10-22 01:16:32 +08:00
微信朋友圈删除评论提醒数字还在点进去什么都没有我是一直不能理解啊。
|
 |
10
hakono 2019-10-22 01:21:50 +08:00
就和上面说的一样，就不取消通知呗，又没问题。，
点赞后取消掉，用户收到通知发现没有被点赞，肯定会知道是别人取消了，这个其实也是符合用户操作逻辑的 如果想真的在用户接收到推送前删除这条消息，那你就只能重新设计表结构了，这没办法的 如果实在没办对原本的表做更改，那你就只能在其他地方记录生成的数据记录的 id 了（如果你的表里连自增的 id 键都没的话，那真的还是建议重新设计表结构了），然后加上点赞用户，被点赞用户，时间之类的信息，取消点赞的时候从这个表反查到 id，然后你搞完就会发现，还不如重新设计表最简单 |
 |
11
Immortal 2019-10-22 02:55:47 +08:00
不知道消息表怎么设计的
我想了下 如下字段不能完成这个需求么： id from to type article_id deleted_at - 关注的消息 article_id 是为空的 - 每种类型的消息都有自己的 type - 取消的时候就给 deleted_at 增加一个取消时间戳，默认为空,或者直接物理删除 这样在取消关注、点赞、删除评论的时候根据 to+article_id 应该能锁定到消息了 |
 |
12
ericgui 2019-10-22 03:09:40 +08:00
搞对列比较合适
至于你说用户取消了，没办法取消的，已经发送的，是取消不了的 |
 |
13
EscYezi 2019-10-22 08:32:50 +08:00 via iPhone
在消息表里加一个逻辑删除字段，取消时置 1，下次用户登录时查消息表数据决定是否提醒。
不过现在 app 好像都要进行推送的吧？ |
|
14
EscYezi 2019-10-22 08:41:52 +08:00 via iPhone
那样的话只能在推送发出之前拦截了，没拦住的话用户打开 app 看到点赞消息出现又消失？😂
|
 |
15
nvkou 2019-10-22 09:04:42 +08:00 via Android
延时队列？反正这种通知不是时间敏感。晚个 1 分钟也没问题。话说为什么要记录用户操作呢。只记录文章有多少点赞不行吗？用户还需要知道自己点赞过什么？
|
 |
16
xuanbg 2019-10-22 09:07:08 +08:00
5 楼正解，取消了再发一条取消的消息才是正常操作。
|
|
17
hhh798 OP |
 |
18
Vtwoguest 2019-10-22 10:01:21 +08:00
很多 App 的逻辑都是关注有提醒，关注之后取消不提醒，点进去就会显示无
另外想问一下表存在记录后接下来的逻辑是如何设计的呢 |
 |
19
liuzhaowei55 2019-10-22 10:16:34 +08:00
如果按现在的消息表这样设计，在消息表里应该关联该消息的事件主体会好一点，不然以后这条消息就是孤岛了。
之前我也是这样设计的，不过后来就取消了消息表的设计，直接在事件主体上标注受影响人对于这条消息的已读未读删除，结构更简单了，毕竟也只是一个事件的通知，一般也就未读已读删除三个操作。 |
 |
20
lufeng08 2019-10-22 11:17:10 +08:00
接着讨论，我们也有消息系统，晚上来看结论，优化我们的消息系统。
|
|
21
hhh798 OP |
 |
22
Vegetable 2019-10-22 11:31:42 +08:00
来换一个顺序，点赞-通知-收到通知-取消点赞。这种情况下，用户已经读到了通知了，系统如果把通知删了，用户会很迷惑，所以唯一能做的就是再发一次取消点赞的通知（没见过谁家做这个功能...）。
这样很简单就可以意识到，通知是不可以删除的，不必特殊处理。 |
 |
23
YUyu101 2019-10-22 12:05:25 +08:00 via Android
点赞应该是变动了 userpost 表，评论是变动了 comment 表，这些记录变动想放同一张表的话就要记录表名、主键、变动类型、变动字段，这样缺点是没有外键，每张表有各自的历史记录表的话可以用外键，但表会很多。这样之后再来一张或几张消息表对应这些历史记录、消息发送对象、已读未读，因为同一个变动可能要通知多个人，消息插入是被动的可以防止死用户占空间，在每次对象上线时开始根据上次上线时间后的变动遍历统计一遍，有取消的删除的可以这时候不加入消息表，历史记录表还是有的，统计完一起插入更新下用户登录时间。怕用户消息太多可以在统计时合并掉，反正消息只是一条消息，记录表里全都有。
|
 |
24
hst001 2019-10-22 12:10:57 +08:00
这个时候对用户来说，报好不报坏未必不是好事
|
Select Language