站内信设计思路之己见（基于上百万用户）
大家都知道站内信，分为少量（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的用户现在只会依据活跃用户而占用存储空间，而不活跃的用户，根本不用再去为浪费的存储空间而烦恼了。
看完之后，想必大家对站内信设计，也有自己的看法观点，欢迎评价，提出您宝贵的意见，让我学到更多考虑问题的角度，谢谢
转载请注明出处，这是对作者写的文章的肯定和支持，谢谢。
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息查看更多关于站内信设计思路之己见（基于上百万用户）的详细内容...