设计篇--站内信设计思路之己见（基于上百万用户）

 

你们都知道站内信，分为少许（10-999用户），中量（1000-99999用户），大量（100W用户）不一样的站内信架构，消耗存储空间，和效率也是不一样的。

本人基于最大的架构，来于你们共同讨论，站内信这个小功能，究竟要怎么设计，才能更节约空间。下面是

你们都知道站内信，分为少许（10-999用户），中量（1000-99999用户），大量（100W用户）不一样的站内信架构，消耗存储空间，和效率也是不一样的。

本人基于最大的架构，来于你们共同讨论，站内信这个小功能，究竟要怎么设计，才能更节约空间。下面是基于我我的的一些看法：

站内信的功能是：

一、用户与用户之间的交流，像邮件形式。

二、管理员给用户发站内信。

三、管理员群发消息给全部的用户（对于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表中插入一条记录，格式如同这样子：

这条系统消息已经记录在数据库中

如今用户都读不到这条信息，如今模拟，假若有一个用户登录了账号，接下来要作的就是：

　　一、首先读取Recid中有没有与该用户Id匹配的消息，目前结果是没有；

　　二、以后再匹配RecId=0的系统消息数量，如今有一条，MessageID=1；

　　三、而后就对系统消息表SysMessag 插入现有的一条记录插入以后，也就像下面这样：

　　　　

　　　　SysStatus状态默认为未读0。

　　四、若是有多条信息的话，就执行多条插入操做，（什么？会有不少系统消息？  你见过系统消息有上百条？就算有上百条，数据执行100次插入 我想问题也不大吧？ - -||）

　　五、最后取消息的总数Message+SysMessag，反馈给前台，如今是1。

模拟到此结束。     o(∩_∩)o

用户已读系统消息只能修改存于SysMessag 中的SysStatus的状态，不能去修改Message表中的状态，我想这个是可控的。

（什么？你说用户发消息的时候输入RecId=0？这个权限问题你不能控制？ 那我真不知道说什么好了。^_^ ）

有100W的用户如今只会依据活跃用户而占用存储空间，而不活跃的用户，根本不用再去为浪费的存储空间而烦恼了。