站内信数据库设计思路

站内短信的实现
服务器君一共花费了115.440 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

站内短信很常见,比如系统需要发消息给用户,用户登录之后可以看到这些消息。

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--已读

本文地址:http://www.nowamagic.net/librarys/veda/detail/431,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/431

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《重构:改善既有代码的设计》 福勒(Martin Fowler) (作者), 熊节 (译者)

《重构:改善既有代码的设计》清晰地揭示了重构的过程,解释了重构的原理和最佳实践方式,并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机和技术。《重构:改善既有代码的设计》提出的重构准则将帮助你一次一小步地修改你的代码,从而减少了开发过程中的风险。

更多计算机宝库...