首页 / MYSQL / 站内信数据库设计思路
站内信数据库设计思路
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了站内信数据库设计思路，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1987字，纯文字阅读大概需要3分钟。
内容图文
站内短信很常见，比如系统需要发消息给用户，用户登录之后可以看到这些消息。 Msg表，字段如下： idint自增长idsenderidint 外键关联发送者idtitlevarchar(128) 短信标题contentvarchar(512) 短信内容createTime datatime 发信时间status tinyint 发件箱中的
站内短信很常见，比如系统需要发消息给用户，用户登录之后可以看到这些消息。
Msg表，字段如下：
id int 自增长id senderid int 外键关联发送者id title varchar(128) 短信标题 content varchar(512) 短信内容 createTime datatime 发信时间 status tinyint 发件箱中的状态：0--普通；1--删除
一张user_has_msg表，字段如下：
id int departmentid int 部门群发的时候外键关联部门id，可以为空 receverid int 外键关联收信人，可以为空 msgid int 外键关联短信息 status tinyint 收件箱状态：0--普通；1--删除 readStatus tinyint 阅读状态：0--未读；1--已读
这样设计是基于如下考虑的：
首先，msg表包含了发件箱所需要的所有信息，程序的时候写发件箱的时候可以只考虑操作一张数据库表。
第二，user_has_msg中，departmentid主要考虑的是存在大量的按照部门群发的可能，这样的话，群发给一个部门的时候之需要在两张表上个记录一条数据，而不需要在user_has_msg中记录该部门员工数条记录。
但是，后来这个方案被我自己和同事讨论后否决了，原因如下：
首先，departmentid的存在使得没有用户可以删除收件箱中的站内信，因为删除了，其他人的收件箱里也看不到。
第二，msg表不能保证显示完所有的发件箱所需要的数据，因为只有着一张表的是后读不出来收件人信息。
修改后的版本是：
将msg修改为只保纯粹的信息的表：
id int 自增长id title varchar(128) 短信标题 content varchar(512) 短信内容 createTime datatime 发信时间
将user_has_msg修改为保存各种关系和状态的表：
id int senderid int 外键关联发送者id receverid int 外键关联收信人 msgid int 外键关联短信息 sendStatus tinyint 发件箱中的状态：0--普通；1--删除 receveStatus tinyint 收件箱状态：0--普通；1--删除 readStatus tinyint 阅读状态：0--未读；1--已读
内容总结
以上是互联网集市为您收集整理的站内信数据库设计思路全部内容，希望文章能够帮你解决站内信数据库设计思路所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。