我将如何在 MongoDB 中设计这个模式？
让我们以聊天室为例。
我是否应该创建 2 个集合：Room 和 Messages，并将房间详细信息（标题、描述）与消息（正文/日期/作者）分开存储？ Messages 集合有一个名为“Room”的字段，该字段链接到 Room 的 ObjectId。
或者
我应该创建 1 个集合，名为 Room。然后Room里面，有一系列的消息？
最佳实践是什么？你会做什么？
Let's take an example of a chat room.
Should I create 2 collections: Room and Messages, and store the room details (title, description) separately from Messages (body/date/author)? The Messages collection would have a field called "Room" that links to the ObjectId of Room.
OR
Should I create 1 collection, called Room. And then inside Room, there is an array of messages?
What is the best practice? What would you do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会倾向于你的第一选择。除了 16MB 可能太小（我以前见过一些非常繁忙的聊天室）之外，单独存储消息可以为您提供更大的灵活性。房间甚至不需要知道与它关联的消息 - 只需创建一次并根据需要通过您的
Roomid 查询消息即可。I would lean toward your first choice. Aside from the fact that 16MB may be too small (I've seen some pretty busy chat rooms in my days), storing the messages separately allows for some greater flexibility on your part. The room doesn't even need to know what messages are associated with it - just create it once and query for messages by your
Roomid as needed.模式设计问题已经在这里被问过很多次了。请研究一下，因为解决方案总是相同的 - 您只需思考一下并将它们应用到您自己的用例中：
MongoDB 架构设计 - 实时聊天
Mongodb 架构设计
MongoDB 模式设计 - 许多小文档或者更少的大文档？
用您自己问题的 Y 替换答案中的 X 确实不应该那么困难。
此外：标准文档也适用（并且对您的问题非常明确）：
http://www.mongodb.org/display/DOCS/Schema+Design
Schema design questions have been ask numerous times here. Please research since the solutions are always the same - you just have to think for a moment and apply them to your own usecase:
MongoDB Schema Design - Real-time Chat
Mongodb schema design
MongoDB Schema Design - Many small documents or fewer large documents?
It really should not be that hard replacing X in the answer with Y of your own problem.
In addition: the standard documentation applies as well (and is pretty much explicit on your problem):
http://www.mongodb.org/display/DOCS/Schema+Design