站内信系统数据库设计
2014-10-30 11:16
806 查看
很多网站系统(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)
站内信系统数据库设计
站内信不同于电子邮件,电子邮件通过专门的邮件服务器发送、保存。而站内信是系统内的消息,说白了,站内信的实现,就是通过数据库插入记录来实现的。
站内信有两个基本功能.
一:点到点的消息传送。用户给用户发送站内信;管理员给用户发送站内信。
二:点到面的消息传送。管理员给用户(满足一定条件的用户群)群发消息。
主要分析点到面的站内信设计
第一种情况:(用户量比较少百级别)
这种情况,由于用户量比较少,因此没有必要考虑数据库的优化,采用简单的一张表就可以实现了,对系统的设计也来的比较简单,后期也比较容易维护,是典型的用空间换时间的做法。
表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)
相关文章推荐
- 汽车租赁公司CIS数据库系统的设计
- 大型 ERP 等数据库系统常见的几种设计 [转自jacklondon的专栏]
- 图书管理系统数据库设计
- 【账务管理系统】数据库设计篇
- 图书管理系统数据库设计
- 大型 ERP 等数据库系统常见的几种设计
- 人事管理系统(数据库课程设计)
- 一个简单的酒店系统的数据库设计
- Oracle平台应用数据库系统的设计与开发
- 《解剖PetShop》系列之 一:系统架构设计 二:数据访问层之数据库访问设计 三:数据访问层之消息处理
- 大型ERP等数据库系统常见的几种设计
- 非常弱弱地浅谈聊天机器人(人工智能)系统的数据库设计想法
- 非常弱弱地浅谈聊天机器人(人工智能)系统的数据库设计想法
- (转)一个简单的酒店系统的数据库设计
- 数据库原理_课程设计_自贡公交查询系统
- 零配件系统的数据库设计问题
- 数据库设计:系统编码规则的自定义
- 工资管理系统的数据库、表结构设计,请做过的朋友指教!TKS!
- 大型ERP等数据库系统常见几种设计
- 用三层架构与设计模式思想部署企业级数据库业务系统开发