MongoDB关系：嵌入还是引用？


MongoDB relationships: embed or reference?

我是MongoDB的新手 - 来自关系数据库背景。 我想设计一个带有一些注释的问题结构，但我不知道用于评论的关系：embed还是reference？

有一些注释的问题，比如stackoverflow，会有这样的结构：

1
2
3
4
Question
    title = 'aaa'
    content = bbb'
    comments = ???

首先，我想使用嵌入式注释(我认为在MongoDB中建议使用embed)，如下所示：

1
2
3
4
5
6
Question
    title = 'aaa'
    content = 'bbb'
    comments = [ { content = 'xxx', createdAt = 'yyy'},
                 { content = 'xxx', createdAt = 'yyy'},
                 { content = 'xxx', createdAt = 'yyy'} ]

很清楚，但我担心这种情况：如果我想编辑指定的评论，我该如何获取其内容及其问题？ 没有_id让我找到一个，也没有question_ref让我找到它的问题。 (我是新手，我不知道如果没有_id和question_ref，有没有办法做到这一点。)

我必须使用ref而不是embed吗？ 然后我必须创建一个新的评论集合？

相关讨论

这更像是一门艺术，而不是一门科学。有关Schema的Mongo文档是一个很好的参考，但这里有一些需要考虑的事项：

  • 尽可能多地投入

    Document数据库的乐趣在于它消除了大量的连接。你的第一直觉应该是尽可能多地放在一个文件中。因为MongoDB文档具有结构，并且因为您可以在该结构中有效地进行查询(这意味着您可以获取所需文档的一部分，因此文档大小不应该让您担心太多)没有立即需要将数据标准化你会在SQL中。特别是除了其父文档之外没有用的任何数据应该是同一文档的一部分。

  • 可以从多个位置引用到其自己的集合中的单独数据。

    这不是一个"存储空间"问题，因为它是一个"数据一致性"问题。如果许多记录将引用相同的数据，则更高效且更不容易更新单个记录并在其他位置保留对它的引用。

  • 文档大小注意事项

    MongoDB对单个文档施加了4MB(16MB，1.8)大小限制。在GB数据的世界中，这听起来很小，但它也是3万条推文或250个典型的Stack Overflow答案或20张闪烁的照片。另一方面，这比在一个典型的网页上一次可能想要呈现的信息要多得多。首先考虑什么会使您的查询更容易。在许多情况下，对文档大小的关注将是过早优化。

  • 复杂的数据结构：

    MongoDB可以存储任意深层嵌套数据结构，但不能有效地搜索它们。如果您的数据形成树，林或图形，则实际上需要将每个节点及其边缘存储在单独的文档中。 (请注意，还有专门为此类数据设计的数据存储，也应考虑这些数据存储)

    还有人指出，不可能在文档中返回元素的子集。如果您需要挑选每个文档的几个部分，将它们分开将更容易。

  • 数据一致性

    MongoDB在效率和一致性之间进行权衡。规则是对单个文档的更改始终是原子的，而对多个文档的更新绝不应该假定为原子。也无法"锁定"服务器上的记录(您可以使用例如"锁定"字段将其构建到客户端的逻辑中)。在设计架构时，请考虑如何保持数据的一致性。通常，您保存在文档中的越多越好。

对于您所描述的内容，我会嵌入注释，并为每个注释指定一个带有ObjectID的id字段。 ObjectID中嵌入了一个时间戳，因此您可以使用它而不是根据需要创建。

相关讨论

通常，如果实体之间存在一对一或一对多关系，嵌入就很好，如果您有多对多关系，则引用很好。

相关讨论

If I want to edit a specified comment, how to get its content and its question?

您可以按子文档查询：db.question.find({'comments.content' : 'xxx'})。

这将返回整个问题文件。要编辑指定的注释，您必须在客户端上找到注释，进行编辑并将其保存回数据库。

通常，如果您的文档包含一个对象数组，您将发现这些子对象需要在客户端进行修改。

相关讨论

好吧，我有点迟了但仍想分享我的架构创建方式。

我有一些可用一个词描述的模式，就像你在经典的OOP中所做的那样。

例如。

  • 评论
  • 帐户
  • 用户
  • 博文
  • ...

每个模式都可以保存为Document或Subdocument，因此我为每个模式声明了这一点。

文献：

  • 可以作为参考。 (例如，用户发表评论 - >评论对用户有"制造者"的引用)
  • 在您的应用程序中是"根"。 (例如，博文 - >有关于博客帖子的页面)

子文档：

  • 只能使用一次/永远不是参考。 (例如，评论保存在博文中)
  • 在您的应用程序中永远不是"根"。 (评论只显示在博客页面中，但页面仍然是关于博客帖子)
相关讨论

我在自己研究这个问题时遇到了这个小小的演讲。我很惊讶它的布局，信息和它的呈现方式。

http://openmymind.net/Multiple-Collections-Versus-Embedded-Documents

它总结如下：

As a general rule, if you have a lot of [child documents] or if they are large, a separate collection might be best.

Smaller and/or fewer documents tend to be a natural fit for embedding.

相关讨论

我知道这已经很老了但是如果你正在寻找关于如何只返回指定注释的OP问题的答案，你可以像这样使用$(查询)运算符：

1
db.question.update({'comments.content': 'xxx'}, {'comments.$': true})
相关讨论

是的，我们可以使用文档中的引用。就像sql i join一样填充另一个文档。在mongo db中，他们没有连接来映射一个到多个关系文档。相反我们可以使用populate来实现我们的场景..

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var mongoose = require('mongoose')
  , Schema = mongoose.Schema

var personSchema = Schema({
  _id     : Number,
  name    : String,
  age     : Number,
  stories : [{ type: Schema.Types.ObjectId, ref: 'Story' }]
});

var storySchema = Schema({
  _creator : { type: Number, ref: 'Person' },
  title    : String,
  fans     : [{ type: Number, ref: 'Person' }]
});

填充是使用来自其他集合的文档自动替换文档中的指定路径的过程。我们可以填充单个文档，多个文档，普通对象，多个普通对象或从查询返回的所有对象。我们来看一些例子。

更好的是，您可以访问：http：//mongoosejs.com/docs/populate.html

相关讨论

我创建了这个quizz作为参考，知道你是否应该使用一个或另一个

http://indie-rok.github.io/embedded-vs-reference-mongo-db

实际上，我很好奇为什么没有人谈到UML规范。根据经验，如果你有一个聚合，那么你应该使用引用。但如果它是一个组合，那么耦合更强，你应该使用嵌入式文档。

你会很快理解为什么它是合乎逻辑的。如果对象可以独立于父对象存在，那么即使父对象不存在，您也希望访问它。由于您无法将其嵌入到不存在的父级中，因此必须将其嵌入到自己的数据结构中。如果存在父级，只需通过在父级中添加对象的引用将它们链接在一起。

真的不知道这两种关系有什么区别？
这是一个解释它们的链接：
UML中的聚合与组合

相关讨论

If I want to edit a specified comment, how do I get its content and
its question?

如果您已跟踪注释的数量和要更改的注释的索引，则可以使用点运算符(例如)。

你可以做f.ex.

1
2
3
4
5
6
7
8
db.questions.update(
    {
       "title":"aaa"      
    },
    {
       "comments.0.contents":"new text"
    }
)

(作为编辑问题内部评论的另一种方式)