Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

MongoDB Data Modeling With Document Structure

DZone's Guide to

MongoDB Data Modeling With Document Structure

Let's take a look at MongoDB data modeling with document structure as well as referenced and embedded documents.

· Database Zone ·
Free Resource

Read the 2019 State of Database DevOps Report for the very latest insights

MongoDB  Data Modeling

MongoDB Data Modeling

We know that MongoDB is a document-oriented database or NoSQL database. It is a schema-less database or we can say, it has a flexible schema. Unlike the structured database, where we need to determine table’s schema in advance, MongoDB is very flexible in this area.

MongoDB deals in collections, documents, and fields. We can have documents containing different sets of fields or structures in the same collection. Also, common fields in a collection can contain different types of data. This helps in easy mapping.

The key challenge in MongoDB data modeling is balancing the requirements of the application. Also, we need to assure the performance aspect effectively while modeling. Let’s point out some requirements while MongoDB Data Modeling taking place.

  1. Design schema according to the need.
  2. Objects which are queried together should be contained in one document.
  3. Consider the frequent use cases.
  4. Do complex aggregation in the schema.

MongoDB Document Structure

There can be two ways to establish relationships between the data in MongoDB:

  • Referenced Documents
  • Embedded Documents

 MongoDB Data Modeling

Referenced Documents

Reference is one of the tools that store the relationship between data by including links from one data to another. In such data, a reference to the data of one collection will be used to collect the data between the collections. We can say, applications resolve these references to access the related data. These are normalized data models.

Reference relationships should be used to establish one to many or many to many relationships between documents. Also, when the referenced entities are frequently updated or grow indefinitely.

MongoDB Document Structure

Embedded Documents

These can be considered as de-normalized data models. As the name suggests, embedded documents create relationships between data by storing related data in a single document structure. These data models allow applications to retrieve and manipulate related data in a single database operation.

Embedded documents should be considered when the embedded entity is an integral part of the document and not updated frequently. It should be used when there is a contained relation between entities and they should not grow indefinitely.

MongoDB Document Structure

Considerations for MongoDB Data Modeling

Some special consideration should be given while designing a data model of MongoDB. This is for a high per performance-centrichly scalable and efficient database. The following aspects should be considered for MongoDB Data Modeling.

Data Usage

While designing a data model, one must consider that how applications will access the database. Also, what will be the pattern of data, such as reading, writing, updating, and deletion of data. Some applications are read centric and some are write-centric. There are possibilities that some data is used frequently whereas some data is completely static. We should consider these patterns while designing the schema.

Document Growth

Some updates increase the size of the documents. During initialization, MongoDB assigns a fixed document size. While using embedded documents, we must analyze if the subobject can grow further out of bounds. Otherwise, there may occur performance degradation when the size of the document crosses its limit. MongoDB relocates the document on disk if the document size exceeds the allocated space for that document.

Atomicity

Atomicity in contrast to the database means operations must fail or succeed as a single unit. If a parent transaction has many sub-operations, it will fail even if a single operation fails. Operations in MongoDB happen at the document level. No single write operation can affect more than one collection. Even if it tries to affect multiple collections, these will be treated as separate operations. A single write operation can insert or update the data for an entity. Hence, this facilitates atomic write operations.

However, schemas that provide atomicity in write operations may limit the applications to use the data. It may also limit the ways to modify applications. This consideration describes the challenge that comes in a way of data modeling for flexibility.

This was all about MongoDB Data Modeling Tutorial. Hope you like our explanation.

Conclusion

Hence, now we are familiar with the MongoDB Data Modeling. We have seen how can we model the data in MongoDB without degrading its performance. Moreover, we saw the MongoDB Document Structure: Reference and Embedded Documents. At last, we discuss some important considerations for MongoDB Data Modeling. In next MongoDB Tutorial, we will learn how to create and drop a database. Furthermore, if you have any query, feel free to ask in a comment section.

Read the 2019 State of Database DevOps Report for latest insights into DevOps adoption among SQL Server professionals, and the benefits and challenges of including the database in DevOps initiatives

Topics:
mongo db ,nosql ,database ,data modeling ,atomicity ,mongodb document structure ,nosql database

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}