通告消息提醒的数据库设计Word格式.docx

通告消息提醒的数据库设计Word格式.docx

《通告消息提醒的数据库设计Word格式.docx》由会员分享，可在线阅读，更多相关《通告消息提醒的数据库设计Word格式.docx（4页珍藏版）》请在冰点文库上搜索。

平台撤销通告。

平台删除通告。

平台查询通告。

用户查看通告。

用户查询通告。

数据库特点

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

1.2消息Message（站内短信）：

用户之间互相发消息，好比是手机短信。

可以针对一个消息进行回复。

分为实时消息和非实时消息。

用户发送消息。

可以是个人向个人发消息，个人向群体发消息，群体向个人发消息，群体向群体发消息。

个人向多个用户发消息。

用户查看消息。

用户回复消息。

用户标记消息已读。

用户查询消息。

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

3提醒Remind：

一般情况下，提醒对于被提醒者来说是被动的。

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

统计性的提醒：

相关内容的个数变化，统计相关内容的个数。

又可以分为实时统计和登录统计。

弹出窗口提醒：

弹出一个窗口，提醒用户发生变化的内容，或者点击可以跳转到相应的窗口显示结果。

又可以分为登录之后提醒距离上次登录之间发生的影响；

和实时的提醒。

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

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

弹出窗口提醒，提醒的格式是统一的。

格式例如：

提醒的对象，提醒的内容，提醒的优先级（紧急，高，普通，不同优先级，有不同的颜色）。

2设计

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

数据库表

2.1平台向单个用户发通告

添加公告的时候，直接将用户编号写在通告表中。

用户阅读之后修改响应的标记。

刚开始考虑单个用户，就直接在通告表添加几个字段，反正是1对1的关系。

后来觉得可以变相的理解一下，分开两张表，是的通告表尽量还是存放通告相关的信息，应该更好一点吧。

通告表

编号

标题

内容

发布时间

是否撤销

撤销时间

是否删除

删除时间

优先级

用户编号

用户类型

是否阅读

阅读时间

2.2平台向多个用户发通告

添加公告记录的同时【通告对象】表中添加多个用户相应的记录。

用户阅读之后修改【通告对象】表响应的标记。

通告对象表

通告编号

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

添加通告，通告信息中附带有用户类型信息。

用户根据自己的类型查看通告，阅读之后，在【用户标记】表中添加记录。

在【用户标记】表中存在的通告，就是历史通告，不存在的就是新通告。

用户标记表

2.4平台向全部用户发通告

添加通告，只有通告的相关信息。

2.5综合比较

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

3相关业务描述

3.1添加通告

单个用户：

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

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

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

通告表添加一条记录

3.2阅读公告

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

修改用户标记表中的记录全部用户：

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

用户标记表添加阅读记录

3.3发现新通告的规则

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

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

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

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

3.4查询

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

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

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

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