Video Transcript (English)

When working with any database, it’s important to understand how the data is stored because this has an impact on data security, scalability, and overall database performance.

When using MongoDB’s flexible document model, you can move quickly during development without sacrificing the robustness needed for production.

In this video, we’ll discuss the details of the document model that make it easy and efficient to work with. Specifically, we’ll cover:

The structure of a MongoDB document,

JSON and BSON,

How MongoDB handles data of different shapes and types, also called polymorphic data,

and

Some limits you should be aware of when working with documents.

Let’s get into it.

Documents are the smallest unit of data in MongoDB.

MongoDB stores multiple documents in collections.

The collections are housed by a database, which may reside on one or multiple nodes within a cluster.

Every MongoDB document begins and ends with curly braces.

Inside the curly braces, the data is composed of field-value pairs, where the field is the identifier of a piece of data, and the value is the data itself.

In this example from our movie database application, we have fields like 'title' with a value of Goldfinger , 'year' with a value of 1964 , and 'plot' where the value contains a summary of the movie plot.

The field names in MongoDB documents are strings. They must be unique within a document and should be clear and descriptive.

This is a good practice because it makes the data easier to understand. For example, a field name like “username” for the value “sflores” is preferred to something like “u-n”.

The value of a field can be of various data types. These range from simple data types such as strings, numbers, or Booleans, or more complex structures like mixed type arrays and document objects.

A golden rule of MongoDB is that data that is accessed together should be stored together in a single document. This allows MongoDB to store diverse data within a single document such as in this example where we have information about a movie.

To do this, we can use arrays or embedded documents. In this example, the `imdb` field contains embedded documents.

Now that we have the basics out of the way, let’s dig into more detail. MongoDB documents are similar to JSON objects. While JSON is great for representing data, MongoDB stores documents in a format called BSON, or Binary JSON.

Unlike JSON, which is a human-readable text format, BSON is a binary format used for internal storage and transmitting data over the network.

BSON is an extension of JSON that is designed to be lightweight, traversable, and efficient. It also provides additional data types beyond standard JSON, such as dates, objectID, and timestamps. We’ll discuss this in more depth in the next lesson.

We’ve already mentioned that MongoDB’s document model is flexible. What does that mean?

First, it can handle polymorphic data, which is data of different shapes and types. Fields might contain several types of data that vary from one document to the next within a collection.

Traditional relational databases have a rigid schema, which makes it difficult to handle some types of data. But with MongoDB’s flexible schema, documents can hold all sorts of data, including

text, geospatial, time-series, graph data, and more.

For example, in our movies data, some documents include metacritic scores, while others do not.

Another advantage of MongoDB’s flexible schema is the ease of adding new fields.

There’s no need to do a complete rebuild of the data immediately. We can update existing documents as needed.

For example, none of the documents in our movies collection currently list filming locations. But let’s say we want to add a field to track filming locations. All we need to do is begin including them in new or updated documents.

We don't have to rebuild and reindex our entire collection.

We just do it!

Check out our videos on schema lifecycle management to learn more about schema evolution.

Although MongoDB’s document model offers a lot of flexibility, there are some limits to be aware of when working with documents.

There’s a maximum document size of 16 MB,

In addition, within a single document, you can have a maximum of 100 levels of nesting, or levels of embedded documents.

The 16-megabyte size limit ensures efficient data retrieval and management. It prevents documents from consuming too much memory or bandwidth, which can degrade performance and make the database harder to manage.

Likewise, the 100 levels of nesting limit is designed to ensure that the underlying code for MongoDB can be done simply and efficiently.

You'll likely never need more than a few levels of nesting, but it's good to know that the limit exists.

Nice work in this lesson! Let’s recap what you learned.

First, we covered the structure of a MongoDB document. Data in documents is composed of field-value pairs, where the field is the identifier of a piece of data, and the value is the data itself. Moreover, to store related data together, we can use arrays and embedded documents within documents.

We also discussed the differences between JSON and BSON and how this relates to documents.

You also learned why the document model is considered a flexible schema, and the benefits that provides.

Finally, we discussed two limits you should be aware of when working with documents - the maximum document size of 16 MB and a limit of 100 levels of nesting.

We mentioned in this lesson that documents handle a variety of data types. So let’s talk about that more in the next lesson. See you there!