我正在使用MongoDB中的嵌入式文档作为Rails 3应用程序。我喜欢我可以使用嵌入式文档，并且值都是通过一个查询返回的，而且数据库服务器上的负载更少。但是，如果我希望我的用户能够更新真正应该在文档之间共享的属性，会发生什么呢。这种操作在MongoDB中可行吗？还是我最好使用普通的基于id的关系？如果基于身份的关系是可行的，它会在很大程度上影响性能吗？
如果您需要了解有关应用程序或数据的其他信息，我很乐意让您知道我正在使用什么。
具有所有文档共享的许多属性的文档。
Person
name: string
description: string
想要使用这些属性的文档：
Post
(references many people)
body: string
这一切都取决于您以后要对Person模型做什么。我知道至少有一个工作示例（使用MongoDB的博客），它的开发人员将用户数据保存在他们发表的评论中，并为整个博客使用一个集合。好吧，好吧，他用第二个作为他的"标签云"：）他不需要保留所有评论的集中列表，他不在乎。他的博客包含了他以前所有网站/博客的合并数据？，总共有近6000个员额。帖子包含评论，评论包含用户，用户有电子邮件，他为每个评论帖子的用户提供了"订阅评论"选项，授权由外部OpenID服务聚合器（Loginza）处理，他将从Loginza回复获得的用户电子邮件和他们的"登录令牌"保存在他们的cookie中。所以功能还是不错的。
所以，真正的问题是——以后你将如何处理你的用户？如果你真的觉得你需要一个单独的集合（你要让用户有集中的控制面板，有基于站点的注册，你要做以用户为中心的功能等等），就把它分开。如果不是-保持简单并享受乐趣：）
这取决于您希望在跨文档中共享哪些用户信息。比方说，如果你有用户和用户有电子邮件。不一定要将电子邮件转移到单独的集合中，因为每个用户不会超过1020100封电子邮件。但是，如果用户说有一些大的相关信息总是在增长，比如博客文章，那么就必须将其转移到单独的集合中。
所以答案取决于用户文档结构。如果你展示你的用户文档结构和你计划转移到单独的集合中的内容，我将帮助你做出决定。