公告系统的数据库设计探索

我在网上查找了几种方案。

方案一:

建立一个类似于这样的表

announcements
    - title
    - content
    - create_time
    - update_time

优点:节省空间,一条数据即可通知所有用户
缺点:弊端是无法体现用户是否已读公告。

改进方案

建立一张新表

announcement_user
    - announcement_id
    - user_id

当用户已读该公告的话,则插入一条数据。

方案二:

表结构:

announcements
    - title
    - content
    - is_read
    - create_time
    - update_time

优点:可以直接体现用户是否已读公告
缺点:占用的空间大,需要给每一个用户发送一条

该如何选择或改进?

这两种方案的缺点都很大,请问有什么更好改进的方案吗?

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
Epona
最佳答案

个人感觉要有已读功能的话就是方案一和方案二 2选1了。 还有一种稍微好点的就是在缓存(Redis)中记录是否已读。

4年前 评论
讨论数量: 11
Epona

个人感觉要有已读功能的话就是方案一和方案二 2选1了。 还有一种稍微好点的就是在缓存(Redis)中记录是否已读。

4年前 评论

你改进的目的是什么呢, 是担心后期数据量过大查询效率下降吗?如果是担心数据量过大,可以使用MySQL的merge存储引擎分表。如果数据量不是很大, 我觉得没必要优化什么,直接

announcements 
    - user_id
    - title 
    - content 
    - is_read 
    - create_time
    - update_time
4年前 评论
Clusteramaryllis (楼主) 4年前
waynelam 4年前
一念沧海一念桑田 (作者) 4年前
一念沧海一念桑田 (作者) 4年前

https://v2ex.com/t/466997#reply14

这里有相关的话题 供题主参考

4年前 评论

优选方案一! 方案二冗余数据太多,本来一个公告只需要一次sql操作,方案二你有500W用户难道要插入500W条记录? 其他的就是该加缓存就加缓存了

4年前 评论

mysql存公告记录,用nosql(如mongo)存阅读状态记录,通过用户+公告ID作为一个key,方便快速查出是否已读

4年前 评论
Clusteramaryllis

@terranc @Epona 请问如果不想让新用户有旧的未读公告该怎么办呢?

4年前 评论
Clusteramaryllis (作者) (楼主) 4年前
Atzcl

方案一 + 改进方案够用了

4年前 评论

我们公司的做法是,数据库保存一条公告记录,然后用 Redis 的 Bitmap 保存阅读状态,消息的 ID 作为 Key,用户 ID 作为 offset,阅读状态作为 value

4年前 评论
circle

请问如果需要添加类似 平台页面(目的是针对用户访问不同平台、不同页面时显示公告)这样的字段时,应该怎样设计比较好呢?

4年前 评论
Clusteramaryllis (楼主) 4年前

额,,,还要不要加点,部门公告啥的 :see_no_evil:

4年前 评论
Clusteramaryllis (楼主) 4年前

不用想,当然是方案一。至于 Nosql 之类我都不会考虑,简单问题复杂化。

4年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!