在参与者和对话之间建立一对多关系是否存在可伸缩性问题？

Question

我有一个数据库设计，如以下实体关系图（ERD）所示：

https://app.dbdesigner.net/designer/schema/0-social_media-00a3405c-0bcd-4809-9f8e-e86c1b8e5f33

我想知道在Participants和Conversation之间是否应该建立一对多关系。

问题：需要多次加入

问题是，每当我们要获取id的{​​{1}}中的Participants中的Conversation来广播Messages时，都需要加入一个连接。

不仅如此，我们还需要content中的Messages，这意味着我们需要在三个表之间进行两个联接。

问题

• 是否有更可扩展的解决方案？
• 是否存在瓶颈问题？
• 除了额外的奖金以外，桌子还有其他问题吗？

Answer 1

可伸缩，因为：

如果一个对话吸引了越来越多的用户（以其参与者的身份），则只需在表Participants中添加行。想象一下，对话中有一个成员列表，叫做Participants。

如果删除了一个用户帐户，则只需在表Participants中搜索其所有记录（关联的对话）并将其删除。

这两种情况仅意味着对Participants的修改，而对话保持不变。

关联实体

这种User与Conversation的成员资格或关系是通过所谓的关联关系，关联表桥接的。 em>或associative entity。意味着一个User可以参加0个或多个Conversations，反之亦然，一个Conversation可以拥有（至少）一个（创建者）或多个Users

因此，实体/表Participants的作用就像一个桥梁：连接两个方面/观点。

广播示例

用户A希望向频道/会话1广播消息。现在，系统需要确定所有收件人。因此，仅在表“参与者”中找到对话1，并找到其参加用户A，B和C。除了发件人A以外的所有人都应接收广播：B和C。

没有没有加入。 简单查询：SELECT user_id FROM participants WHERE conversation_id = 1 AND user_id <> 'A'。给定Message，并假设user_id可以直接用作目的地（电子邮件地址，电话号码等），系统可以立即将广播发送出去。