工作中遇到一个站内信的设计问题。本来想往上查查有啥资料没。没想到看了别人的思路，自己没思路了。就直接转载了。

首先，解释一下什么叫站内信？

百度百科中的解释：

???? “站内信”是为方便会员商务信件往来而设的服务功能，类似于邮箱，主要由收件箱、发件箱、草稿箱和垃圾箱三部分组成，但该功能仅对网站的注册会员开放。

　 　“站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存。而“站内信”是系统内的消息，其实就是通过数据库插入记录来实现的。 　　

?? ?? “站内信”有两个基本功能。一：点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。二：点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。

???????? 点到点的消息传送很容易实现，本文不再详述。下面将根据不同的情况，来说说“站内信”的群发是如何实现的。

　　第一种情况，站内的用户是少量级别的。（几十到上百）

　　这种情况，由于用户的数量非常少，因此，没有必要过多的考虑数据库的优化，采用简单的表格，对系统的设计也来的简单，后期也比较容易维护，是典型的用空间换时间的做法。

　　数据库的设计如下：

??????? 表名：Message

　　ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；Message：站内信内容；Statue：站内信的查看状态；PDate：站内信发送时间；

　　如果，某一个管理员要给所有人发站内信，则先遍历用户表，再按照用户表中的所有用户依次将站内信插入到Message表中。这样，如果有56个用户，则群发一条站内信要执行56个插入操作。这个理解上比较简单，比较耗损空间。

　　某一个用户登陆后，查看站内信的语句则为：

　　Select * FROM Message Where RecID=‘ID' OR RecID=0

　　第二种情况，站内的用户中量级别的（上千到上万）。

　　如果还是按照第一种情况的思路。那发一条站内信的后果基本上就是后台崩溃了。因为，发一条站内信，得重复上千个插入记录，这还不是最主要的，关 键是上千乃至上万条记录，Message字段的内容是一样的，而Message有大量的占用存储空间。比方说，Message字段有100个汉字，占用 200个字节，那么5万条，就占用200×50000=10000000个字节=10M。简单的一份站内信，就占用10M，这还让不让人活了。

　　因此，将原先的表格拆分为两个表，将Message的主体放在一个表内，节省空间的占用

　　数据库的设计如下：

　　表名：Message

　　ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；MessageID：站内信编号；Statue：站内信的查看状态；

　　表名：MessageText　

　　ID：编号；Message：站内信的内容；PDate：站内信发送时间；

　　在管理员发一封站内信的时候，执行两步操作。先在MessageText表中，插入站内信的内容。然后在Message表中给所有的用户插入一条记录，标识有一封站内信。

　　这样的设计，将重复的站内信的主体信息（站内信的内容，发送时间）放在一个表内，大量的节省存储空间。不过，在查询的时候，要比第一种情况来的复杂。

　　第三种情况，站内的用户是大量级的（上百万），并且活跃的用户只占其中的一部分。

　　大家都有这样的经历，某