最近要做个预警列表的已读未读功能,这个是推送过来的,我想了想,已读未读是针对用户来的,每个用户对应着一套列表的已读未读,假如我们每条数据都给每个用户对应读取状态,那是多对多的关系,得多少数据啊,想想都可怕。
方案一:刚开始也懒,想让android和ios自己存取数据的读取状态,他们相对于我很少的数据量就能解决,但是他们存本地是有一个缺点的,假如清理缓存和卸载,这个已读未读就将全部清空,显然不合理,只有存服务器端才是正确的选择,
方案二:我想了想,假如我将一个用户的未读id拼成一个字符串放在一张表中,用户点击一条数据,删除一个未读的id,当删除完的时候删除整条数据,这样感觉还不错,但是有一个问题,就是假如消息一直堆加,而用户一直未读,就会一直追加到爆炸,也不是很合理,我又想了想,假如我设定最大的未读数量为50,超过50条会删除前边的一条,追加上最新的一条,这样也挺不错的,这是一种可行的办法。
方案三:我感觉这种方式跟用户的订单类似,也是不断递增的,订单跟用户也是相关联的,也是多对多的关系,订单都能存数据库中,我的列表的多对多也能存在数据库中,那就存吧,因为我的是推送过来的,只有开着消息开关的才会给用户推送消息,所以消息也并不都是所有的,那就存数据库吧,点击修改消息状态就好了,这样逻辑最简单。
网友评论