MongoDB和嵌入式文档,用例很好

时间:2011-06-07 05:40:51

标签: ruby-on-rails ruby-on-rails-3 mongodb mongoid

我在MongoDB中使用嵌入式文档来获取Rails 3应用程序。我喜欢我可以使用嵌入式文档,并且所有值都返回一个查询,并且数据库服务器上的负载较少。但是,如果我希望我的用户能够更新真正应该跨文档共享的属性,会发生什么。 MongoDB这种操作是否可行,或者我最好使用基于正常身份的关系吗?如果基于ID的关系是可行的方式,它会在很大程度上影响性能吗?

如果您需要了解有关应用程序或数据的任何其他信息,我很乐意告诉您我正在使用的内容。

包含所有文档共享的许多属性的文档。

Person
name: string
description: string

想要使用这些属性的文档:

Post
(references many people)
body: string

2 个答案:

答案 0 :(得分:1)

这取决于您想要共享交叉文档的用户信息。让我们说如果你有用户和用户有电子邮件。不会将电子邮件移动到单独的集合中,因为每个用户不会超过10,20,100封电子邮件。但是,如果用户说有一些总是在增长的大相关信息,比如博客文章那么就可以将其转移到单独的集合中。

所以答案取决于用户文档结构。如果您显示用户文档结构以及计划进入单独集合的内容,我将帮助您做出决定。

答案 1 :(得分:1)

这完全取决于您稍后将如何处理您的Person模型。我知道至少有一个工作示例(使用MongoDB的博客),其开发人员将用户数据保存在他们制作的评论中,并为整个博客使用一个集合。好吧,好吧,他使用第二个作为他的“标签云”:)他只是不需要保留所有评论者的集中列表,他不在乎。他的博客包含了他以前所有网站/博客的综合数据,总共有近6000个帖子。帖子包含评论,评论包含用户,用户有电子邮件,每个评论一些帖子的用户都有“订阅评论”选项,授权由外部OpenID服务聚合器(Loginza)处理,他保持用户电子邮件来自Loginza响应和他们的cookie中的“登录令牌”。所以功能非常好。

所以,真正的问题是 - 您以后将如何处理您的用户?如果您真的觉得需要一个单独的集合(您将允许用户拥有集中控制面板,进行基于站点的注册,您将使用以用户为中心的功能等),请将其分开。如果不是 - 保持简单并享受乐趣:)