需求1. 系统管理员推送站内消息可以按照用户标签推送,可以按照特定用户推送,可以按照部门推送,可以全部推送。
需求2. 前端用户可以查看已读消息,未读消息,未读消息条数,可以删除消息。
最简单的方式,推送表 记录。 用户ID和消息ID。 不管按照什么推送,都批量给这个表里插入记录就行了。
但如果全部推送,经常动不动就插入好几万条记录。数据量很大。
如果按照其他的设计,实现用户可删除消息,和用户的未读消息有些难。 请问数据库和系统设计上改如何做比较好呢?
需求1. 系统管理员推送站内消息可以按照用户标签推送,可以按照特定用户推送,可以按照部门推送,可以全部推送。
需求2. 前端用户可以查看已读消息,未读消息,未读消息条数,可以删除消息。
最简单的方式,推送表 记录。 用户ID和消息ID。 不管按照什么推送,都批量给这个表里插入记录就行了。
但如果全部推送,经常动不动就插入好几万条记录。数据量很大。
如果按照其他的设计,实现用户可删除消息,和用户的未读消息有些难。 请问数据库和系统设计上改如何做比较好呢?
哈哈 我现在就是在这两个方案里纠结了很久很久了。。方案1 插入数据量巨大。 并且查询也要从 巨大的表里查询。但是查询语句很简单。 方案二 插入简单,数据量也少。 但是查询语句非常绕的。各种in查询。
5 回答3.2k 阅读✓ 已解决
3 回答3.6k 阅读✓ 已解决
2 回答2.8k 阅读✓ 已解决
5 回答1.4k 阅读
3 回答1.2k 阅读✓ 已解决
1 回答1.6k 阅读✓ 已解决
2 回答2k 阅读
1.用户表:用户标签
2.推送表:推送消息,面向标签,id
3.用户消息表:用户id,推送表id,状态。
上面是关系型的,缺点是要插入很多数据。
或者在用户表里面加一个 字段 用json 数组形式记录用户已经读的消息id。不要用户消息表。用的时候根据用户的标签去查找消息,然后根据已经读的id 去过滤。推送消息的时候直接在表里面插入一条数据,但是这样很。。。。。