62,267
社区成员
发帖
与我相关
我的任务
分享关于站内信，求一思路
公司项目站内信模块我已基本完成，但现在有一难点，不知道如何解决，请高手指导一下。
站内信分为两种，一种系统站内信，一种用户间的站内信，当发送系统站内信时我的想法是就添加一条记录让所有用户都可以看到，未读信息的样式是字体加粗，如果就系统站内信一条的话该怎样控制每个用户是否已读的状态呢？
站内信分为两种，一种系统站内信，一种用户间的站内信，当发送系统站内信时我的想法是就添加一条记录让所有用户都可以看到，未读信息的样式是字体加粗，如果就系统站内信一条的话该怎样控制每个用户是否已读的状态呢？
...全文
请发表友善的回复…
发表回复
滴滴 2011-12-08
- 打赏
- 举报
“站内信”有两个基本功能。一：点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。二：点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。
点到点的消息传送很容易实现，本文不再详述。下面将根据不同的情况，来说说“站内信”的群发是如何实现的。
第一种情况，站内的用户是少量级别的。（几十到上百）
这种情况，由于用户的数量非常少，因此，没有必要过多的考虑数据库的优化，采用简单的表格，对系统的设计也来的简单，后期也比较容易维护，是典型的用空间换时间的做法。
数据库的设计如下：
表名：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表中给所有的用户插入一条记录，标识有一封站内信。
这样的设计，将重复的站内信的主体信息（站内信的内容，发送时间）放在一个表内，大量的节省存储空间。不过，在查询的时候，要比第一种情况来的复杂。
第三种情况，站内的用户是大量级的（上百万），并且活跃的用户只占其中的一部分。
大家都有这样的经历，某日看一个网站比较好，一时心情澎湃，就注册了一个用户。过了一段时间，由于种种原因，就忘记了注册时的用户名和密码，也就不再登陆了。那么这个用户就称为不活跃的。从实际来看，不活跃的用户占着不小的比例。
我们以注册用户2百万，其中活跃用户只占其中的10%。
就算是按照第二种的情况，发一封“站内信”，那得执行2百万个插入操作。但是其中的有效操作只有10%，因为另外的90%的用户可能永远都不会再登陆了。
在这种情况下，我们还得把思路换换。
数据库的设计和第二种情况一样：
表名：Message
ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；MessageID：站内信编号；Statue：站内信的查看状态；
表名：MessageText
ID：编号；Message：站内信的内容；PDate：站内信发送时间；
管理员发站内信的时候，只在MessageText插入站内信的主体内容。Message里不插入记录。
那么，用户在登录以后，首先查询MessageText中的那些没有在Message中有记录的记录，表示是未读的站内信。在查阅站内信的内容时，再将相关的记录插入到Message中。
这个方法和第二种的比较起来。如果，活跃用户是100%。两者效率是一样的。而活跃用户的比例越低，越能体现第三种的优越来。只插入有效的记录，那些不活跃的，就不再占用空间了。
点到点的消息传送很容易实现，本文不再详述。下面将根据不同的情况，来说说“站内信”的群发是如何实现的。
第一种情况，站内的用户是少量级别的。（几十到上百）
这种情况，由于用户的数量非常少，因此，没有必要过多的考虑数据库的优化，采用简单的表格，对系统的设计也来的简单，后期也比较容易维护，是典型的用空间换时间的做法。
数据库的设计如下：
表名：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表中给所有的用户插入一条记录，标识有一封站内信。
这样的设计，将重复的站内信的主体信息（站内信的内容，发送时间）放在一个表内，大量的节省存储空间。不过，在查询的时候，要比第一种情况来的复杂。
第三种情况，站内的用户是大量级的（上百万），并且活跃的用户只占其中的一部分。
大家都有这样的经历，某日看一个网站比较好，一时心情澎湃，就注册了一个用户。过了一段时间，由于种种原因，就忘记了注册时的用户名和密码，也就不再登陆了。那么这个用户就称为不活跃的。从实际来看，不活跃的用户占着不小的比例。
我们以注册用户2百万，其中活跃用户只占其中的10%。
就算是按照第二种的情况，发一封“站内信”，那得执行2百万个插入操作。但是其中的有效操作只有10%，因为另外的90%的用户可能永远都不会再登陆了。
在这种情况下，我们还得把思路换换。
数据库的设计和第二种情况一样：
表名：Message
ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；MessageID：站内信编号；Statue：站内信的查看状态；
表名：MessageText
ID：编号；Message：站内信的内容；PDate：站内信发送时间；
管理员发站内信的时候，只在MessageText插入站内信的主体内容。Message里不插入记录。
那么，用户在登录以后，首先查询MessageText中的那些没有在Message中有记录的记录，表示是未读的站内信。在查阅站内信的内容时，再将相关的记录插入到Message中。
这个方法和第二种的比较起来。如果，活跃用户是100%。两者效率是一样的。而活跃用户的比例越低，越能体现第三种的优越来。只插入有效的记录，那些不活跃的，就不再占用空间了。
以专业开发人员为伍 2011-06-17
- 打赏
- 举报
晕。
你写出测试用例，就可以开发了。纠结它什么数据库表就能代表需求？
你写出测试用例，就可以开发了。纠结它什么数据库表就能代表需求？
lichking911 2011-06-17
- 打赏
- 举报
额，刚才在某空间看了一思路。既然LZ问了，我就现学现卖了。
数据库表用两个
一个信息表：存收、发人，读取标志，内容ID，ID
另一个内容表 ：存内容，发信时间，ID
当发系统信息时，只插入内容表。等用户登录时查询一下在内容ID里没有的内容项，插入到信息表。能有效节约不活跃用户所占用的资源。不过此情况只适合于系统群发站内信。混入用户站内信就要变了。因为单从内容表你分不清谁发给谁。
LZ的思路的话不如做个超链接跑马灯在页面上面，点过的不就变颜色了？
现学现卖，献丑了。有BUG的地方还请指正
原帖地址：
http://apps.hi.baidu.com/share/detail/37922353
数据库表用两个
一个信息表：存收、发人，读取标志，内容ID，ID
另一个内容表 ：存内容，发信时间，ID
当发系统信息时，只插入内容表。等用户登录时查询一下在内容ID里没有的内容项，插入到信息表。能有效节约不活跃用户所占用的资源。不过此情况只适合于系统群发站内信。混入用户站内信就要变了。因为单从内容表你分不清谁发给谁。
LZ的思路的话不如做个超链接跑马灯在页面上面，点过的不就变颜色了？
现学现卖，献丑了。有BUG的地方还请指正
原帖地址：
http://apps.hi.baidu.com/share/detail/37922353
luey97 2010-08-31
- 打赏
- 举报
烦啊，困惑ing
xyanyue 2010-06-09
- 打赏
- 举报
可以将信内容和收件人两表分开
将收件人表中添加已读标记
将收件人表中添加已读标记
APP开发王 2010-06-09
- 打赏
- 举报
友情帮顶下！顺便学习学习！
RHCL 2009-04-24
- 打赏
- 举报
喏～～若不用每个用户加一条数据．可以折中去做
在系统信息加一个字段，保存已读用户ID．用,或其他分开．不过，如果用户太多的话就有点．．．．
IsReadUser
１，２，３，４，５，．．．
在系统信息加一个字段，保存已读用户ID．用,或其他分开．不过，如果用户太多的话就有点．．．．
IsReadUser
１，２，３，４，５，．．．
huming_h 2009-04-24
- 打赏
- 举报
顶楼上
rtdb 2009-04-24
- 打赏
- 举报
只能每人加一条记录了，标志读没读过
浪漫幕末 2009-04-24
- 打赏
- 举报
可以采用ajax long poll 进行提示用户有新消息。
搜索server push，comet 即可。
当然也可以一直ajax轮询
搜索server push，comet 即可。
当然也可以一直ajax轮询
JavCof 2009-04-24
- 打赏
- 举报
我个人感觉那样设计不太合理，空间复杂度是降低了，但是用户是否已经读取该信息，就必须新增加字段。
数据库设计
--------------------
系统站内信编号 系统站内信标题 已经阅读的用户编号
1 标题1 10000,10002,10003,10008...
只能是这样的结构，到时候用户读取该条系统站内信的时候就和上表关联查询...
个人感觉还是把传统的做法比较好，系统站内信是一种广播形式（批量），用户间的站内信是一种点对点的形式。
数据库设计
--------------------
信笺编号 发送人编号 是否阅读
1 000001 1
2 000002 1
数据库设计
--------------------
系统站内信编号 系统站内信标题 已经阅读的用户编号
1 标题1 10000,10002,10003,10008...
只能是这样的结构，到时候用户读取该条系统站内信的时候就和上表关联查询...
个人感觉还是把传统的做法比较好，系统站内信是一种广播形式（批量），用户间的站内信是一种点对点的形式。
数据库设计
--------------------
信笺编号 发送人编号 是否阅读
1 000001 1
2 000002 1
浪漫幕末 2009-04-24
- 打赏
- 举报
系统给用户发的话，一个用户插一条数据，这是必要的重复，用户自己可以删除他收到的信息。
用户给用户发也是这样，用户给多个用户发也是这样，一个用户一份（插一条）。
设计一个flag标记，打开后置一，表示是否已看。
可以根据需要保存用户已发的信息，就像发邮件时保存已发邮件一样。可以设置一个flm（分类码）
1表示发出的邮件，2表示收到的邮件
用户给用户发也是这样，用户给多个用户发也是这样，一个用户一份（插一条）。
设计一个flag标记，打开后置一，表示是否已看。
可以根据需要保存用户已发的信息，就像发邮件时保存已发邮件一样。可以设置一个flm（分类码）
1表示发出的邮件，2表示收到的邮件
sayluyun 2009-04-24
- 打赏
- 举报
在数据库多加一个字段 新短信为 1 看过为 0 或者其他··
