群发“站内信”的实现(续)

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

  ID:4;SendID=1;Message=Good;PDate:2010-4-9

在这种情况下,我们还得把思路换换。

  有网友提出,如果站内信的对象不是全体而是一部分呢?抱歉,这个也不在本文讨论之列,你可以对我的表进行扩展,以达到你的要求。

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

 

这个方法和第二种的比较起来。如果,活跃用户是100%。两者效率是一样的。而活跃用户的比例越低,越能体现第三种的优越来。只插入有效的记录,那些不活跃的,就不再占用空间了。

 

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

  ID:编号;RecID:接受者编号;MessageID:站内信编号;Statue:站内信的查看状态;

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

 

就算是按照第二种的情况,发一封“站内信”,那得执行2百万个插入操作。但是其中的有效操作只有10%,因为另外的90%的用户可能永远都不会再登陆了。

  感谢各位网友的交流。我在此想说的是,我们设计一个系统,必须得结合实际情况,根据实际情况来制定,比能达到一个比较理想的状况。

表名:Message

 

数据库的设计和第二种情况一样:

  这样一来,这个用户下次登陆的时候,由于Message表中有相应的记录,也不会提示用户看站内信。

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

  前几日,发布了博客“群发“站内信”的实现”,得到广大网友呼应,在此表示感谢。

ID:编号;SendID:发送者编号;RecID:接受者编号;MessageID:站内信编号;Statue:站内信的查看状态;

  

ID:编号;Message:站内信的内容;PDate:站内信发送时间;

  ID:编号;SendID:发送者编号;Message:站内信的内容;PDate:站内信发送时间;

ID:编号;SendID:发送者编号;RecID:接受者编号;Message:站内信内容;Statue:站内信的查看状态;PDate:站内信发送时间;

  先看看,第三种情况。站内的用户是大量级的(上百万)。

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

  看了网友的留言。发现大家对文中的前两种情况没有什么异议,对第三种方案争议颇多。我在此再把我的第三种情况详细的阐述一下,和大家交流。另外,本文的主体主要放在“群发”(也就是点到面),至于“单发”(点到点),不在本文的讨论之列。

表名:MessageText

  ID:55;RecID=7;MessageID=4;Statue=删除

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

  假设,网站用户200万,其中活跃用户40万。

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

  表名:MessageText