聊天的数据库架构：私人和群组

Question

我正在尝试设计具有私人聊天和群聊功能的数据库架构。这是我到目前为止所得到的：

所以 - 理论是，即使用户只是在一对一的私人聊天中，他们仍然会被分配一个“roomID”，他们发送的每条消息都指向那个room。
要找出他们参与的所有房间，我可以从表中选择一个列表participants来找出。

这没关系，但是我觉得这张room桌子有点多余，因为我真的不需要房间名称，我可以省略它，只需使用participants桌子并SELECT DISTINCT roomID FROM particpants找出各个房间。

谁能向我解释一个更好的结构或为什么我应该保留房间桌子？

Answer 1

您的架构看起来非常好，您可能会看到其他人（包括今天的我）以前或多或少具有相同的结构（将不同聊天的消息存储在单个数据库表中，用于一对一和群聊的数据库架构，创建像 facebook 和 gmail 的线程私人消息系统）。我真的很想指出，你的视觉表现是最好的，它很容易理解和遵循:)

在一般情况下，我认为有“房间”（“聊天”，“对话”）是有道理的，即使你有没有具体的性能在此刻（因为它可能是name，posting_allowed，type（也就是说，如果你重复使用相似的结构不仅对私人信息和聊天，但 ie 到带有评论的公共帖子）等等。具有单个索引 ID 的单个表应该非常快并且开销接近于零，但是它可以很容易地进行扩展，而无需修改所有现有代码（即一天您决定在name聊天中添加一个。将 roomID 逻辑“隐藏”在participants表中既不透明也不高效（即，当您需要找到聊天的下一个 ID 时），我不建议这样做。