欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

站内信数据库设计思路

程序员文章站 2024-01-18 23:45:28
...

站内短信很常见,比如系统需要发消息给用户,用户登录之后可以看到这些消息。 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--已读