站内私信的数据库表设计问题

[natici]

我看过discuz x3的私信设计，是由2个表来记录的。一个是记录私信内容，id为自增主键；另一个表是user_id和私信id的对应关系记录表。
这样设计的话，若要对站内所有会员发送私信（或称系统通知），若有1e个注册会员，那么就会在第二个表内插入了1e条记录了。
感觉这样设计不靠谱啊，不知道有没哪位大侠有更好的设计思路？

[ACMAIN_CHM]

没什么不好啊。这样的设计非常符合范式的要求。 最多是，发给全站的消息的处理。可以用某个特殊用户ID比如 -100，然后所有的人查询中都取 where uid =myuid and uid = -100

[Rotel-刘志东]

可以在一张表上实现的。无需建立两张表处理。 关键还是看具体的需求。

[natici]

引用 1 楼 ACMAIN_CHM 的回复:

没什么不好啊。这样的设计非常符合范式的要求。 最多是，发给全站的消息的处理。可以用某个特殊用户ID比如 -100，然后所有的人查询中都取 where uid =myuid and uid = -100

where uid =myuid and uid = -100 这个不是空集吗？没看懂你的意思...

[natici]

引用 2 楼 lzd_83 的回复:

可以在一张表上实现的。无需建立两张表处理。 关键还是看具体的需求。

其实我的问题重点在那一亿条数据。先不说发一次全站通知要多久，光这数据量就挺吓人的了，要是站内活动在一段时间内过于密集而需要频繁发全站通知，那么第二个表岂不是短时间内就插入了几十亿甚至几百亿条数据？

[yumenfeiyu945]

引用 4 楼 natici 的回复:

[quote=引用 2 楼 lzd_83 的回复:] 可以在一张表上实现的。无需建立两张表处理。 关键还是看具体的需求。

其实我的问题重点在那一亿条数据。先不说发一次全站通知要多久，光这数据量就挺吓人的了，要是站内活动在一段时间内过于密集而需要频繁发全站通知，那么第二个表岂不是短时间内就插入了几十亿甚至几百亿条数据？[/quote] 如果真要发这么多，不会是一次发出，也不会是在一个库的一个表上

[ACMAIN_CHM]

引用 3 楼 natici 的回复:

[quote=引用 1 楼 ACMAIN_CHM 的回复:] 没什么不好啊。这样的设计非常符合范式的要求。 最多是，发给全站的消息的处理。可以用某个特殊用户ID比如 -100，然后所有的人查询中都取 where uid =myuid and uid = -100

where uid =myuid OR uid = -100 这个不是空集吗？没看懂你的意思...[/quote] 改为 OR

[natici]

引用 5 楼 yumenfeiyu945 的回复:

如果真要发这么多，不会是一次发出，也不会是在一个库的一个表上

我大概了解你的想法。你的意思是，当注册用户有1亿这个数量级的时候，网站就算挺大型的了，数据库应该已经是分表/分库甚至分布到不同服务器上储存了，是这样的意思么？ 那么，我把这个数字改小为100万吧。这样子，每次发送系统通知也要发100万条吧？ 至于你提及到的不会是一次发出，discuz x3也不是一次发出，是分批发的，大约100条/次的发。所以我上述也用了“先不说发一次全站通知要多久”这个字眼。 我的想法是，能不能全站通知只发一条就行，每一位用户都能收到。这样的话表要怎么设计呢？ 我初步的想法跟ACMAIN_CHM差不多，也是想用一个字段进行私信类型约束。

[yumenfeiyu945]

引用 7 楼 natici 的回复:

[quote=引用 5 楼 yumenfeiyu945 的回复:]如果真要发这么多，不会是一次发出，也不会是在一个库的一个表上

我大概了解你的想法。你的意思是，当注册用户有1亿这个数量级的时候，网站就算挺大型的了，数据库应该已经是分表/分库甚至分布到不同服务器上储存了，是这样的意思么？ 那么，我把这个数字改小为100万吧。这样子，每次发送系统通知也要发100万条吧？ 至于你提及到的不会是一次发出，discuz x3也不是一次发出，是分批发的，大约100条/次的发。所以我上述也用了“先不说发一次全站通知要多久”这个字眼。 我的想法是，能不能全站通知只发一条就行，每一位用户都能收到。这样的话表要怎么设计呢？ 我初步的想法跟ACMAIN_CHM差不多，也是想用一个字段进行私信类型约束。[/quote] 不同的设计有不同的局限性，如果通知就一条，那么每个用户是否已经查看，或者是否删除，又需要另一个关联表来存放

[natici]

好的，我明白了。原来是我多虑了，哈哈。