单系统站内信数据库设计思路

第一版设计

需求 ：单用户之间通信（融合了用户反馈需求）
数据库设计：Message内容和收发者存在一张表中

message表：
这里一条Message存两次，类似邮件服务。

status:已读、未读、已删

每当发信者发消息时，就向数据库中写入两条数据，相当于推送式。

推送式：
    优势：在用户量（百、千）和消息量较少时，数据库操作效率高，无需联表查询；
    劣势：不适合群发，重复保存文本内容。

比方说，Message字段有100个汉字，占用200个字节，那么5万条，就占用200×50000=10000000个字节=10M。简单的一份站内信，就占用10M，这还让不让人活了。

第二版设计

需求：增加*企业管理员*和*系统管理员*的通知功能，即特殊用户的一对多功能
数据库设计：两张表，message保存消息内容，messagelog保存关系

message表

type：private：单对单 、 public：企业通知、 global：系统通知；
from_id:保存了发信者的userid，因为信的发送者是固定的，和发送日期、信息内容一样是固有信息可以放在一起，若放在messagelog中冗余。
from_status：message在发送者处的状态。同样是三种。

messagelog表

单用户间发件处理：
发送邮件，插入message和messagelog表各一条记录。（推送式）

企业或者系统发件处理（通知）：
发送邮件，插入message一条记录，在用户读取收件箱时从message中拉取通知。（拉取shi）

拉取式：
    优点：“不用一次性插入N条，且不会产生无效的记录”。只有活跃用户才保存收取通知的记录，发件后再未登录的用户不会保存。
    缺点：联表查询，时间复杂度更高

显示一个用户的收件箱内容流程：

1. 通过userid取到用户信息（所属企业id、注册时间）；
2. 查询rec_id=userid的记录,取message_id和rec_status;
3. （处理通知）查询messagelog表中，符合条件(type=GLOBAL or (type=PUBLIC and company_id= user.company )) and create_time > user.registertime 这些notice，把这些notice和2中的message_id集取交集，非交集中的notice显示未读状态，其他信息按2中读取的rec_status显示。

【新增解释：
】

以上还有messag可见有效期的简单处理，用户注册前的通知不可被用户收到；

其他

1.考虑当用户的company字段变更时对之前那些收到的company通知处理,个人认为在转企时变更用户其他信息时，也把原company的通知也同步到用户的messagelog记录中；也可以不管那些未读的原comopany通知；也可以把已处理的原company通知从messagelog中删除。这个得看业务要求，而且转企这种请求很少发生。
2.考虑普通用户下的1->N，当N不大时，可仍然按单对单的推送式处理；N很大时，就按通知处理方法。

参考

群发“站内信”的实现
群发“站内信”的实现（续）
两年后，再议“站内信”的实现
百万级用户量的站内信群发数据库设计