功能描述

管理员通过后台可向全平台用户发送站内信，站内活跃用户可收到消息，非活跃用户（两年内未登录）不需要收到消息。

需求分析

从上诉需求可以分析，可以抽象出消息实体用来存放具体的消息内容，比如标题、内容、消息，类型发送时间。其次还需要有用户实体存放用户信息以及用户消息关联实体，存放消息和用户之间的关联，大致有用户id、消息id、阅读状态等。

设计思路

推模式与拉模式

一般获取消息的模式分为两种，既推（push）模式和拉（pull）模式。对于数据库表设计来说，也可以分为推、拉两种模式。

推模式：当管理员发送系统通知之后，遍历用户表写通知，相当于对每个用户都在通知表中保存了一份通知消息，在小规模系统上，是可行的，但是用户基数很大的话，会占用大量的存储空间，并且这些空间存储的内容几乎一样。

拉模式：当管理员发送系统通知之后，保存这条消息到通知表中，发布通知的流程就结束了。用户在登陆之后，附带上最近一次登录的时间戳，去请求服务端是否有新的系统通知，如果有，那么获取新通知，写入未读通知字段中，只要存在未读通知，通知图标右上角的小红点就提醒。

所以，对于系统通知这类需求，拉模式是再适合不过的了。根据用户规模在数据库设计时可以分为以下两个方案：

方案一：【适合活跃用户在5万左右】

公告「announce」表结构如下：

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //公告编号；
senderID: {type: ‘string’, required: true} //发送者编号，通常为系统管理员；
title: {type: ‘string’, required: true} //公告标题;
content: {type: ’text’, required: true} //公告内容；
createdAt: {type: ‘timestamp’, required: true} //发送时间；

用户公告表「notify_announce_user」表结构如下：

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号；
announceID: {type: ‘integer’} //公告编号；
recipientID: {type: ‘string’, required: true} //接收用户编号；
createdAt：{type: ‘timestamp’, required: true} //拉取公告时间；
state: {type: ‘integer’, required: true} //状态，已读|未读；
readAt：{type: ‘timestamp’, required: true} //阅读时间；

平台发布一则公告之后，当用户登录的时候去拉取站内公告并插入notify_announce_user表，这样那些很久都没登陆的用户就没必要插入了。「首次拉取，根据用户的注册时间；否则根据notify_announce_user.createdAt即上一次拉取的时间节点获取公告」

方案二：【适合活跃用户在百万-千万左右】

和方案一雷同，只是需要把notify_announce_user表进行哈希分表，需事先生成表：notify_announce_<hash(uid)>。
用户公告表「notify_announce_<hash(uid)>」 表结构如下：

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号；
announceID: {type: ‘integer’} //公告编号；
recipientID: {type: ‘string’, required: true} //接收用户编号；
createdAt：{type: ‘timestamp’, required: true} //拉取公告时间；
state: {type: ‘integer’, required: true} //状态，已读|未读；
readAt：{type: ‘timestamp’, required: true} //阅读时间；