我将站内消息分为：全部用户消息和部分用户消息，某一特定用户消息。
对于“全部用户消息”和“部分用户消息”、“某一特定用户消息”，该如何记录一个用户是否已经读了这条消息。
数据表结构该如何设计好？
要考虑对于新增用户不显示以往发过的“全部用户消息”或“部分用户消息”。
回复内容：
我将站内消息分为：全部用户消息和部分用户消息，某一特定用户消息。
对于“全部用户消息”和“部分用户消息”、“某一特定用户消息”，该如何记录一个用户是否已经读了这条消息。
数据表结构该如何设计好？
要考虑对于新增用户不显示以往发过的“全部用户消息”或“部分用户消息”。
数据结构决定算法。任何时候如果举棋不定，就分析一下数据本身。
-
消息和用户是两个实体，消息的发送是连接实体的关系。
- 无论是全部/部分/单一的消息，都可以用多对多的关系概括之。
则表格结构，按照数据库的范式化规则去设计就可以了：
- msg: ID, ...(其余随意，例如：creation_date, text, sender_ID等）
- msg_deliver: ID, msg_ID, usr_ID, unread(default=true)
- usr: ID, ...(其余随意)
- msg_deliver表格，不应当存在msg_ID和usr_ID都重复的记录（可考虑以索引约束）
则增加消息时需要以下动作：
- 无论如何，都在msg表中创建消息本体
- 为每一个接收者，都在msg_deliver中增加一个条目
- 对全体就增加和usr表一样多的记录，对部分就增加一些记录，一对一就增加1条记录
其他操作：
- 查询未读消息，在msg_deliver表中查询usr_ID和unread==true，如需同时获取消息标题等信息，使用联合查询把msg表拉进来
- 阅读消息时，再次查询msg表，获得消息正文
- 标记已读，查询usr_ID和msg_ID，之后改unread为false
- 全部已读，查询usr_ID，改所有记录的unread为false
- 则对于新用户，在msg_deliver表中自然没有任何关系去连接旧的消息，需求自然解决
其他建议：
- 可以考虑在中间表msg_deliver中，按需要去缓存消息标题、发送者昵称等内容来减少查询次数
- 并发数据量大了，可以再考虑分表，这个分表一般跟随着用户表的分表来做
- 数据积累太多了，可以再考虑归档，把资源尽量用来快速查询近期数据。因为消息越旧查的人越少，所以用的资源反而可以少一些
