通告，消息，提醒DB

首先我们来认识一下通告，消息，提醒这三者的区别和联系。

1.1 通告Bulletin


：

平台发，用户收。分为实时通告和非实时通告。通告有优先级：紧急，高，普通。

平台向单个用户发，平台向多个用户发，平台向某一个用户类型发，平台向全部用户发。

平台发布通告。

平台撤销通告。

平台删除通告。

平台查询通告。

用户查看通告。

用户查询通告。

数据库特点

一般不修改，每个用户一份，或者每个群体一份

1.2 消息Message


（站内短信）：

用户之间互相发消息，好比是手机短信。可以针对一个消息进行回复。分为实时消息和非实时消息。

用户发送消息。可以是个人向个人发消息，个人向群体发消息，群体向个人发消息，群体向群体发消息。个人向多个用户发消息。

用户查看消息。

用户回复消息。

用户标记消息已读。

用户查询消息。

数据库特点

一般不修改，每个用户一份，或者每个群体一份，或者多个用户一份。

3 提醒Remind


：

一般情况下，提醒对于被提醒者来说是被动的。主要是由于外界直接或者间接更新自己相关的信息，对自己产生了影响，自己又不知道的情况下，需要系统主动提醒自己。

统计性的提醒：相关内容的个数变化，统计相关内容的个数。又可以分为实时统计和登录统计。

弹出窗口提醒：弹出一个窗口，提醒用户发生变化的内容，或者点击可以跳转到相应的窗口显示结果。又可以分为登录之后提醒距离上次登录之间发生的影响；和实时的提醒。

通常是由于其他操作附带产生需要提醒的信息。

数据库特点

统计性的提醒，记录需要提醒的个数，以及个数代表的意义。

弹出窗口提醒，提醒的格式是统一的。格式例如：提醒的对象，提醒的内容，提醒的优先级（紧急，高，普通，不同优先级，有不同的颜色）。

今天只是设计一下通告，大家有什么不同意见，尽管提出来。

数据库表

2.1 平台向单个用户发通告

添加公告的时候，直接将用户编号写在通告表中。用户阅读之后修改响应的标记。

刚开始考虑单个用户，就直接在通告表添加几个字段，反正是1对1的关系。后来觉得可以变相的理解一下，分开两张表，是的通告表尽量还是存放通告相关的信息，应该更好一点吧。

通告表

2.2 平台向多个用户发通告

添加公告记录的同时【通告对象】表中添加多个用户相应的记录。用户阅读之后修改【通告对象】表响应的标记。

通告表

通告对象表

2.3 平台向某个用户类型发通告

添加通告，通告信息中附带有用户类型信息。用户根据自己的类型查看通告，阅读之后，在【用户标记】表中添加记录。在【用户标记】表中存在的通告，就是历史通告，不存在的就是新通告。

通告表

用户标记表

2.4 平台向全部用户发通告

添加通告，只有通告的相关信息。在【用户标记】表中存在的通告，就是历史通告，不存在的就是新通告。

通告表

用户标记表

2.5 综合比较

综合前面的设计思路，得出上面的这张图。

3 相关业务描述

3.1 添加通告

 

单个用户：通告表添加一条记录，用户标记表添加一条记录


多个用户：通告表添加一条记录，用户标记表添加多条记录


全部用户：通告表添加一条记录


用户类型：通告表添加一条记录

3.2 阅读公告

 

单个用户：修改用户标记表中的记录


多个用户：修改用户标记表中的记录


全部用户：用户标记表添加阅读记录


用户类型：用户标记表添加阅读记录

3.3 发现新通告的规则

 

单个用户：通告表中有，并且通告对象类型是“单个用户”，并且用户标记表中的未读标记是“0”


多个用户：通告表中有，并且通告对象类型是“多个用户”，并且用户标记表中的未读标记是“0”


全部用户：通告表中有，并且通告对象类型是“全部用户”，并且用户标记表中没有用户的信息


用户类型：通告表中有，并且通告对象类型是“用户类型”，并且用户标记表中没有用户的信息，并且通告表中的用户类型是自己的用户类型

3.4 查询

单个用户：通告表中有，并且通告对象类型是“单个用户”，并且用户标记表中有


多个用户：通告表中有，并且通告对象类型是“多个用户”，并且用户标记表中有


全部用户：通告表中有，并且通告对象类型是“全部用户”


用户类型：通告表中有，并且通告对象类型是“用户类型”，并且通告表中的用户类型是自己的类型

通告，消息，提醒 DB