大家都知道站内信,分为少量(10-999用户),中量(1000-99999用户),大量(100W用户)不同的站内信架构,消耗存储空间,和效率也是不同的。
本人基于最大的架构,来于大家共同讨论,站内信这个小功能,究竟要怎么设计,才能更节约空间。下面是
大家都知道站内信,分为少量(10-999用户),中量(1000-99999用户),大量(100W用户)不同的站内信架构,消耗存储空间,和效率也是不同的。
本人基于最大的架构,来于大家共同讨论,站内信这个小功能,究竟要怎么设计,才能更节约空间。下面是基于我个人的一些见解:
站内信的功能是:
1、用户与用户之间的交流,像邮件形式。
2、管理员给用户发站内信。
3、管理员群发消息给所有的用户(对于100W用户,你要怎么做?)
开门见山,先看看我设计的数据库表关系:
Message表:
MessageID:标识列; SendId:发件人id; RecId:收件人id; TextId:消息id; Status:标识已读1/未读0;
MessageText表:
TextId:标识列; Titel:标题; Text:信件内容; Time:发件时间;
SysMessag表:
SysID:标识列; CustomerID:用户标识列; MessageID:消息标识列; SysStatus:系统消息已读1/未读0;
一个用户需要接收多条系统信息,而每条系统信息则会有一个对应的消息状态,所以这张表是对应没条系统消息的一个状态的判断。
所有标识列都是主键
三张表关系就是这样子:
表设计就是这个样子,用到三张表。
现在需要来检验我的设计的时候了,假如,管理员给所用户群发消息的发送id=0也就是RecId = 0
我需要在Message表中插入一条记录,格式如同这样子:
这条系统消息已经记录在数据库中
现在用户都读不到这条信息,现在模拟,假如有一个用户登陆了帐号,接下来要做的就是:
1、首先读取Recid中有没有与该用户Id匹配的消息,目前结果是没有;
2、之后再匹配RecId=0的系统消息数量,现在有一条,MessageID=1;
3、然后就对系统消息表SysMessag 插入现有的一条记录插入之后,也就像下面这样:
SysStatus状态默认为未读0。
4、如果有多条信息的话,就执行多条插入操作,(什么?会有很多系统消息? 你见过系统消息有上百条?就算有上百条,数据执行100次插入 我想问题也不大吧? - -||)
5、最后取消息的总数Message+SysMessag,反馈给前台,现在是1。
模拟到此结束。 o(∩_∩)o
用户已读系统消息只能修改存于SysMessag 中的SysStatus的状态,不能去修改Message表中的状态,我想这个是可控的。
(什么?你说用户发消息的时候输入RecId=0?这个权限问题你不能控制? 那我真不知道说什么好了。^_^ )
有100W的用户现在只会依据活跃用户而占用存储空间,而不活跃的用户,根本不用再去为浪费的存储空间而烦恼了。