我不能找到非常简单的问题，“最好”的解决方案（或不太）
拥有古典组数据：即连接到用户的帖子，附着发布和用户的意见。
现在，我不能决定如何构建方案/班
在方式是存储USER_ID内的意见和内部。
但是，当我有网页200条的评论，会发生什么？
或者，当我有第N个帖子？
我的意思是它应该是200个的额外请求数据库显示用户信息（如姓名，头像）
另一种方案是用户数据嵌入到每个评论和每个柱。
但首先 - >这是巨大的开销，第二 - >模型系统是越来越损坏（使用mongoalchemy），三阶>用户可以更改自己的信息（如化身）。 什么呢？ 按照我的理解上的评论或帖子巨大的集合更新操作不是简单的操作...
您有什么建议？ 是每页200个请求MongoDB是OK（必须瞄准性能）？
或者可能我只是失去了一些东西...
您可避免N+1数百使用要求的-问题$in -queries。 试想一下：
Post {
PosterId: ObjectId
Text: string
Comments: [ObjectId, ObjectId, ...] // option 1
}
Comment {
PostId: ObjectId // option 2 (better)
Created: dateTime,
AuthorName: string,
AuthorId: ObjectId,
Text: string
}
现在，你可以找到与该帖子的评论$in查询，你也可以很容易地找到特定作者提出的所有意见。
当然，你也可以保存意见作为一个后嵌入式阵列，并执行$in当你获取评论用户信息查询。 这样，你不需要反规范化用户名，但仍没有需要数百个查询。
如果选择非规范化的用户名，你将有当用户改变，例如他的名字不断更新该用户的所有评论。 在另一方面，如果这样的操作不会经常发生，它不应该是一个大问题。 或者，也许它甚至更好存放时，他提出的意见，根据您的要求，用户不得不名。
与嵌入的一个普遍问题是， 不同的作家会写同一个对象 ，所以你将不得不使用原子调节剂 （如$push ）。 这有时很难与映射器使用（我不知道mongoalchemy虽然），一般不太灵活。
我会做什么用的MongoDB将嵌入用户ID到的意见（这是“后”文档结构的一部分）。
为更好的性能三个简单的提示：
1）请务必确保在USER_ID指数
2）使用评论分页方法避免查询200次数据库
3）高速缓存是你的朋友
你可以隐藏用户的对象，这样你就不必每次查询数据库。
我喜欢嵌入用户数据到每个岗位，但是，你要想想，当一个用户的配置文件更新会发生什么的想法？ 必须确保将任何职位被错过。
我建议只是撇去蒙戈如何建议你处理架构开始了。
一般来说，对于“包含”实体之间的关系，埋线应选择。 使用不使用连接会导致数据复制时的链接。
http://www.mongodb.org/display/DOCS/Schema+Design
有从MongoDB的文档相当不错的使用案例： http://docs.mongodb.org/manual/use-cases/storing-comments/便利，它也是用Python写的:-)
