我试图设计一个既能进行私有聊天又能进行群组聊天的数据库模式.以下是我到目前为止得到的信息:
个
所以——理论上，即使用户只是在一对一的私有聊天中，他们仍然被分配了一个"室友"，他们发送的每一条信息都会发送到那room条
这是可以的，但是我觉得room桌有点多余，因为我并不真的需要房间名称，我可以省略它，只需使用participants桌和SELECT DISTINCT roomID FROM particpants桌来查找各个房间.
谁能告诉我一个更好的 struct ，或者为什么我应该保留房间的桌子？
您的模式看起来非常好，您可能会看到其他模式(包括今天的我)的 struct 与以前大致相同(Database schema for one-to-one and group chat06/1657819">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).我真的想指出，你的视觉表现是最好的，它很容易理解和遵循:)
总的来说，我认为拥有"聊天室"("chat"、"conversation")是有意义的，即使你目前没有特定的属性(可能是name、posting_allowed、type(也就是说，如果你不仅将类似的 struct 用于私有消息和聊天，也用于带有 comments 的公开帖子)等等.带有单个索引ID的单表应该非常快，开销几乎为零，但是它可以非常轻松地进行扩展，而无需修改所有现有代码(例如，有一天您决定在聊天中添加name).