我们什么时候应该在 MongoDB 中使用嵌入式文档？

Question

I read a lot about embedding in MongoDB, but still I don't know when to use it. I thought of some scenarios:

I have A collection named UserGroups with these fields:

• _id
• name

Now I want to add an user to Users collection:

1. I should have a groupName field in Users collection and update it when UserGroups collection gets an update.

2. I should add the groupId field in Users collection and perform a join whenever I want the UserGroups.name.

3. I should add the user document as an embedded document to UserGroups collection.

4. Or I should add the userGroup document as an embedded document in Users collection. though, I don't think I should do it.

Which option should I use?

Answer 1

Due to MongoDB schema flexibility, developers no longer have to design the database schema first ieEntity Relationship Diagram . The design of the application comes first, then design the database schema to match the application usage (query, writes, updates, etc). See also Data Modelling .

This is the reason why there is no right/wrong answer on the database schema design. There are various use case for MongoDB, and different applications can leverage different models.

When should we use embedded documents in MongoDB?

Without knowing exactly how your applications will interact with the data, the following answer is only a general guidelines or approach :

Favour the embedding, unless there is a reason not to.

Try to denormalise UserGroup into User first. For example:

{ userid: 1001,
  name: "Reza Tayebi", 
  group: {id: 10,
          name: "Developer"
  }
}

When the relationship is one to few (not many, not unlimited).

The above example is applicable, if a user can either be in one or few groups. If there are more than one but limited to under 5, you may introduce an array. However if a user can be in 20+ or an unlimited number of groups, you should start considering separating groups into another collection.

When retrieval is likely to happen together.

If the retrieval of UserGroups is always associated with a user. For example, either Query some users with their respective groups , or Query some users given a specific group(s) .

When updates are likely to happen at the same time.

If it is likely that you would update Users and UserGroups at the same time. Although starting from MongoDB 4.0, you can use multi-documents transactions if Users and UserGroups are not embedded, a single document transaction would be more performant. See also Atomicity and Transactions .

When the field is rarely updated.

If the name of a group is rarely updated in the collection. For example, if the group name Developers required to be updated to Web Developers for the entire Users collection often, then embedding UserGroups is not suitable.

Again, above are only general guidelines that you should consider before designing your schema, see also the following resources:

• Blog: 6 Rules of Thumb for MongoDB Schema Design Part 1 , Part 2 , and Part 3
• Data Model Examples and Patterns
• Operational Factors and Data Models
• Hybrid Schema Design

UPDATE:

A new resource: Building with Patterns: A Summary . Also worth mentioning, for situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports multi-document Transactions .