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

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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