Second post for the first section of the MongoDB Developer Certification! This part carries 8% weighting and focuses on document Types and Shapes.

Documents in MongoDB are stored as BSON, which is a binary JSON.

BSON is a binary serialization format used to store documents and make remote procedure calls in MongoDB. The BSON specification is located at bsonspec.org.

• BSON overhead: MongoDB uses BSON (Binary JSON) for data storage. There's a small overhead for each document and field.
• Data compression: MongoDB supports compression, which can reduce storage usage.

Documents

Our documents will follow this pattern:

{
  _id: value,  
  field: value,
  field1: value1,
  fieldX: valueX,
}

The _id field is an auto-generated primary key of type ObjectId by default. However, you can assign a custom value to this field using any data type, except arrays or regular expressions.

The _id must be unique throughout the collection. It is immutable and, once set, cannot be changed.

The fieldX can hold any type which I have already discussed in a previous post.

Modeling documents

Reference document

Usually, when we have to model student and their address, we would come up with the idea of splitting them into separate collections (or tables in a relational database).

It's not a problem for MongoDB to store documents like that, using references. As always, it's a trade-off. MongoDB is a preferable database for storing related data together to have faster access.

this away:

collection students

{
  _id: ObjectId("66c1fec432fc73d4982e5ee9"),
  name: "Liam Wilson"
}

collection addresses

{
  _id: ObjectId("66c212ed32fc73d4982e5eea"),
  studentId: ObjectId("66c1fec432fc73d4982e5ee9"),
  street: "",
  zipcode: "",
  city: ""
}

Embedded document

But we can model our 2 collections into one collection and have an embedded document.

Modeling one-to-one relationship

{
  _id: ObjectId("66c1fec432fc73d4982e5ee9"),
  name: "Liam Wilson",
  address: {
    street: "",
    zipcode: "",
    city: ""
  }
}

Modeling one-to-many relationship

{
  _id: ObjectId("66c1fec432fc73d4982e5ee9"),
  name: "Liam Wilson",
  address: [
  {
    street: "",
    zipcode: "",
    city: ""
  }]
}

There are some advantages to doing that. Because our focus is on the certification, I'll save this discussion for another post. Please see the references for more details.

In my opinion, the beauty of MongoDB lies in the flexibility you can apply to a single collection. What I mean is that your model can evolve easily without requiring a ton of migration scripts. However, this approach can also lead to some problems; it's not perfect.

Let's say, we have a collection called students, at first modeling we released our application with documents like this:

example document 1

{
  _id: ObjectId("66bdef3b836c1fad45cc6022"),
  name: "John Brown", 
  birth: "2000-01-01"
}

After a month our application evolved and started tracking the courses.

example document 2

{
  _id: ObjectId("66bdef3b836c1fad45cc6023"),
  name: "Emily Carter", 
  birth: "2001-01-01",
  courses: [
   { 
     name: "Arts",
     professor: "Noah Davis",
     startDate: "2024-06-01",
     endDate: "2024-07-01"
   }
  ]
}

Again, it evolved into something we hadn't planned, missing the students' grades. So, we added two new fields called grades and status.

example document 3

{
  _id: ObjectId("66bdef3b836c1fad45cc6024"),
  name: "Ava Johnson", 
  birth: "2002-09-09",
  courses: [
   { 
     name: "Arts",
     professor: "Noah Davis",
     startDate: "2023-06-01",
     endDate: "2023-07-01"
     status: 2,
     grades: [
     {
        date: "2023-06-05",
        score: 86
     },
     {
        date: "2023-06-15",
        score: 89
     },
     {
        date: "2023-06-25",
        score: 95
     },
     ]
   }
  ]
}

Of course, it was a silly example. But, imagine saving this kind of object into a relational database. You'd need 3 tables and a few joins to retrieve the information. On the other hand, with NoSql, it's possible to get all the information you need directly in one place.

We'll discuss it better along the series.

References

https://www.mongodb.com/docs/manual/core/document/
https://www.mongodb.com/docs/manual/data-modeling/
https://www.mongodb.com/resources/compare/relational-vs-non-relational-databases
https://www.mongodb.com/resources/basics/databases/data-modeling