The Document Model
Objectives
By the end of this lesson, you should be able to:
- Explain what a document database is, and how it differs from a relational one
- Translate a familiar table into an equivalent MongoDB document
- Explain when MongoDB’s flexibility is a genuine advantage, and when it isn’t
💡 Why this matters: Modules 1 through 6 assumed data fits neatly into rows and columns, with a fixed schema enforced by the database. MongoDB doesn’t work that way, this lesson covers what changes, before writing a single line of code.
From a Table to a Document
A students row from Module 1:
| id | name | grade |
|----|--------|-------|
| 1 | Erin | 9 |
The same data as a MongoDB document, a JSON-like object:
{
"_id": "65f1a2b3c4d5e6f7a8b9c0d1",
"name": "Erin",
"grade": 9
}
A collection is MongoDB’s equivalent of a table, a group of documents (the equivalent of rows). The database itself is still called a database. The vocabulary maps directly:
| Relational (PostgreSQL) | Document (MongoDB) |
|---|---|
| Database | Database |
| Table | Collection |
| Row | Document |
| Column | Field |
Primary key (id) |
_id |
What’s Actually Different
A relational table (Module 1) enforces the same columns on every row, migrations (Module 4) are how that structure changes deliberately, over time. A MongoDB collection enforces no such thing by default, two documents in the same collection can have completely different fields:
{ "_id": "1", "name": "Erin", "grade": 9 }
{ "_id": "2", "name": "Jordan", "grade": 10, "clubs": ["chess", "robotics"] }
Both are perfectly valid documents in the same students collection, even though only the second has a clubs field. This is often called being “schemaless”, though in practice, most real applications still want some consistent shape, which is exactly what Mongoose (starting Module 8) adds back on top.
Nesting, Instead of Joining
A relational one-to-many relationship (Module 5) needed a separate table and a foreign key. A document can often just nest the related data directly:
{
"_id": "1",
"name": "Erin",
"grade": 9,
"contact": {
"email": "erin@example.com",
"phone": "555-0100"
}
}
contact is an object nested inside the student document itself, no second table, no JOIN, no foreign key. This works well when the nested data always belongs to, and is only ever read with, its parent, Module 9 covers exactly when nesting like this is the right call, and when it isn’t.
When This Is a Genuine Advantage
- Data that’s naturally nested (a blog post and its comments, a product and its reviews) can be read in a single document fetch, no
JOINneeded. - A collection’s shape can evolve without a formal migration, useful for rapidly changing data.
- Deeply nested, document-shaped data (a user’s full settings object, for example) maps naturally, without breaking it into several tables.
When It Isn’t
- Data with real relationships between many different entities (Module 5’s authors, books, and tags) often still benefits from PostgreSQL’s enforced structure and joins.
- No schema enforcement by default means bugs that a relational database would catch automatically (a missing required field, wrong type) can slip through, unless something like Mongoose adds validation back.
Try It
- Take the
Author/Book/Tagschema from Module 5, and sketch what a singleBookdocument might look like if the author’s name were nested directly inside it instead of referenced by ID. - List two situations where nesting data directly (as MongoDB allows) would be genuinely convenient, based on projects from this course so far.
- Explain, in your own words, why MongoDB’s lack of enforced structure is described as a trade-off, not simply an advantage.
Recap
- MongoDB stores data as documents (JSON-like objects) grouped into collections, the rough equivalent of rows in tables, but without an enforced, fixed structure.
- Relationships that needed a separate table and foreign key in PostgreSQL can often be nested directly inside a single document instead.
- This flexibility is a genuine trade-off, not a strict upgrade, Module 9 covers exactly when to nest and when to reference.
Next lesson: connecting a Node.js application to a real MongoDB database, with the official driver.