站内信系统数据库设计



站内信系统数据库设计

很多网站系统(cms系统、sns系统等)，都有站内信的功能。

站内信不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存。而站内信是系统内的消息，说白了，站内信的实现，就是通过数据库插入记录来实现的。

站内信有两个基本功能.

一:点到点的消息传送。用户给用户发送站内信;管理员给用户发送站内信。

二:点到面的消息传送。管理员给用户(满足一定条件的用户群)群发消息。

 

主要分析点到面的站内信设计

 

第一种情况:(用户量比较少百级别)

这种情况，由于用户量比较少，因此没有必要考虑数据库的优化,采用简单的一张表就可以实现了，对系统的设计也来的比较简单，后期也比较容易维护，是典型的用空间换时间的做法。

表message: id(主键)、sendId(发送者编号)、receiveId(接收者编号)、messageContent（站内信内容）、statue(站内信查看状态)、createDate(站内信发送时间)

 

第二种情况:(用户量中量级别)

如果还是按照第一种那样来设计数据库，那么每次群发一次站内信，就要插入几万条数据，占用字节最大的就是messageContext字段，并且这几万条记录的messageContent内容是相同的。所以要考虑分表来设计了。把messageContext单独抽取到另外一张表中。

表message:id(主键)、sendId(发送者编号)、receiveId(接收者编号)、messageContextId（站内信内容Id）、statue(站内信查看状态)

表messageContext: messageContentId(主键)、messageContent(站内信内容)、createDate

 

第三种情况:(用户量上百万级别)

如果采用第二种情况，其实是做了很多无用的message表插入操作的。因为这几百万用户只有百分之10左右是活跃用户，有很多用户是不登入app(网站)，所以我们得设计当他们登入的时候我们才执行插入操作。数据库的设计和第二种情况是一样的，只是插入的实际我们要重新选择。

 

 

备注:站内信的statue状态应该有三个值(未读、已读、删除状态)。用户点了删除知识逻辑上的删除，并没有在物理层数据库删除。我们给用户一个假象，我们底层的实现就是改变statue状态为删除就ok.(数据是一个企业的核心，虽然这种数据没什么价值)。

为了扩展我们还可以存在messageStatue(站内信状态)、readStatue(用户查看状态)

messageStatue 指的是发给谁(private、public)