您的模式看起来非常好，您可能会看到其他人（包括今天的我自己）或多或少都有相同的结构（Storing messages of different chats in a single database table，Database schema for one-to-one and group chat，Creating a threaded private messaging system like facebook and gmail）。我真的很想指出，你的视觉表现是最好的，它很容易理解和遵循：）
总的来说，我认为拥有“房间”（“聊天”，“对话”）是有意义的，即使你目前没有特定的属性（比如name，posting_allowed，type（即如果您不仅对私人消息和聊天重复使用类似的结构，到具有评论的公共帖子）等等。具有单个索引ID的单个表应该是超级快的，并且开销接近于零，但是它将允许扩展非常容易，而不需要修改所有现有代码（即有一天你决定在聊天中添加一个name）。将roomID逻辑“隐藏”在participants表中既不透明，也不高效（即当你需要找到下一个ID的聊天），我不会建议。

我认为您可能需要对您的领域模型进行一点改进--如果不这样做，很难说您的模式是否“正确”。
以Slack为模型（注意-我没有做过大量的研究，所以细节可能是错误的），你可能会说你的系统有“聊天”。
聊天可以是公开的，即列出供所有用户查看和加入-或私有-即未为所有用户列出，仅可通过邀请获得。
公共聊天必须具有“名称”属性。私人聊天可能有也可能没有名称属性。
聊天可以有2..n个参与者。
默认情况下，所有1-1聊天都以私密方式开始。
可以将私人聊天更改为公共聊天。
在这种情况下，你有一个继承/专门化关系--“private”和“public”是“chat”的子类型。
关系模型在处理继承方面是出了名的糟糕; SO上有很多relatedquestions。

我知道这有点晚，但我已经做了一些这样的，我总是有一个active type bool列在消息表。万一有人说了什么，你可以把它藏起来，但仍然要把它记录下来。以及users表中的user_auth。有时候我会在房间里放一个auth_required -> user.user_auth，以防你想像很多不和谐的声音一样进行层次化的对话，而且在消息栏里总是放一个datetime。这些是最低标准，因为如果你没有它们，你以后会后悔的。

我会这样做更像一个简单的聊天系统与组和私人聊天（两个成员）。
x1c 0d1x的数据
另一个可能性是创建一个表只为组消息和一个私人聊天。（避免组和消息表之间的n：m，或者您将n：m用作一个功能，而不是作为可能的bug /逻辑错误）。如果你想要一个更复杂的聊天系统，看看内维尔库伊特的帖子。
希望我能帮到你。

用于私聊和群聊的数据库模式

的数据