通告消息提醒的数据库设计.docxVIP

通告（公告），消息（站内短信），提醒的数据库设计1 业务描述首先我们来认识一下通告，消息，提醒这三者的区别和联系。1.1 通告Bulletin：平台发，用户收。分为实时通告和非实时通告。通告有优先级：紧急，高，普通。平台向单个用户发，平台向多个用户发，平台向某一个用户类型发，平台向全部用户发。平台发布通告。平台撤销通告。平台删除通告。平台查询通告。用户查看通告。用户查询通告。数据库特点一般不修改，每个用户一份，或者每个群体一份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 查询单个用户：通告表中有，并且通告对象类型是“单个用户”，并且用户标记表中有多个用户：通告表中有，并且通告对象类型是“多个用户”，并且用户标记表中有全部用户：通告表中有，并且通告对象类型是“全部用户”用户类型：通告表中有，并且通告对象类型是“用户类型”，并且通告表中的用户类型是自己的类型