MongoDB 关系:嵌入还是引用? [英] MongoDB relationships: embed or reference?

问题描述

我是 MongoDB 的新手——来自关系数据库背景.我想设计一个带有评论的问题结构，但我不知道评论使用哪种关系:embed 还是reference?

I'm new to MongoDB--coming from a relational database background. I want to design a question structure with some comments, but I don't know which relationship to use for comments: embed or reference?

带有一些评论的问题，例如 stackoverflow，将具有如下结构:

A question with some comments, like stackoverflow, would have a structure like this:

Question
    title = 'aaa'
    content = bbb'
    comments = ???

一开始，我想使用嵌入注释(我认为embed在MongoDB中是推荐的)，像这样:

At first, I want to use embeded comments (I think embed is recommended in MongoDB), like this:

Question
    title = 'aaa'
    content = 'bbb'
    comments = [ { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'} ]

很清楚，但我担心这种情况:如果我想编辑指定的评论，如何获取其内容和问题?没有_id 让我找到一个，也没有 question_ref 让我找到它的问题.(我是新手，如果没有 _id 和 question_ref，我不知道是否有任何方法可以做到这一点.)

It clear, but I'm worried about this case: If I want to edit a specified comment, how do I get its content and its question? There is no _id to let me find one, nor question_ref to let me find its question. (I'm so newbie, that I don't know if there's any way to do this without _id and question_ref.)

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

Do I have to use ref not embed? Then I have to create a new collection for comments?

推荐答案

这与其说是一门科学，不如说是一门艺术.Mongo 架构文档 是一个很好的参考，但这里有一些需要考虑的事项:

This is more an art than a science. The Mongo Documentation on Schemas is a good reference, but here are some things to consider:

• 尽可能多地投入

• Put as much in as possible

文档数据库的乐趣在于它消除了大量的联接.您的第一直觉应该是在一个文档中尽可能多地放置.因为 MongoDB 文档具有结构，并且因为您可以在该结构内有效地查询(这意味着您可以获取所需的文档部分，因此文档大小不应该太担心)，所以没有立即需要对数据进行规范化，例如你会在 SQL 中.尤其是，除了其父文档之外没有用的任何数据都应该是同一文档的一部分.

The joy of a Document database is that it eliminates lots of Joins. Your first instinct should be to place as much in a single document as you can. Because MongoDB documents have structure, and because you can efficiently query within that structure (this means that you can take the part of the document that you need, so document size shouldn't worry you much) there is no immediate need to normalize data like you would in SQL. In particular any data that is not useful apart from its parent document should be part of the same document.

将可以从多个地方引用的单独数据放入自己的集合中.

Separate data that can be referred to from multiple places into its own collection.

这与其说是一个存储空间"，不如说是一个存储空间"；问题，因为它是数据一致性"问题.如果许多记录将引用相同的数据，则更新单个记录并在其他地方保留对它的引用会更有效且更不容易出错.

This is not so much a "storage space" issue as it is a "data consistency" issue. If many records will refer to the same data it is more efficient and less error prone to update a single record and keep references to it in other places.

文档大小注意事项

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

MongoDB imposes a 4MB (16MB with 1.8) size limit on a single document. In a world of GB of data this sounds small, but it is also 30 thousand tweets or 250 typical Stack Overflow answers or 20 flicker photos. On the other hand, this is far more information than one might want to present at one time on a typical web page. First consider what will make your queries easier. In many cases concern about document sizes will be premature optimization.

复杂的数据结构:

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

MongoDB can store arbitrary deep nested data structures, but cannot search them efficiently. If your data forms a tree, forest or graph, you effectively need to store each node and its edges in a separate document. (Note that there are data stores specifically designed for this type of data that one should consider as well)

它也被指出比不可能返回文档中元素的子集.如果您需要从每个文档中挑选一些位，将它们分开会更容易.

It has also been pointed out than it is impossible to return a subset of elements in a document. If you need to pick-and-choose a few bits of each document, it will be easier to separate them out.

数据一致性

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

MongoDB makes a trade off between efficiency and consistency. The rule is changes to a single document are always atomic, while updates to multiple documents should never be assumed to be atomic. There is also no way to "lock" a record on the server (you can build this into the client's logic using for example a "lock" field). When you design your schema consider how you will keep your data consistent. Generally, the more that you keep in a document the better.

对于您所描述的内容，我会嵌入评论，并为每个评论提供一个带有 ObjectID 的 id 字段.ObjectID 中嵌入了一个时间戳，因此您可以根据需要使用它而不是在 at 处创建.

For what you are describing, I would embed the comments, and give each comment an id field with an ObjectID. The ObjectID has a time stamp embedded in it so you can use that instead of created at if you like.

这篇关于MongoDB 关系:嵌入还是引用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！