What is MongoDB? Document Databases vs Relational

MongoDB Fundamentals — What is MongoDB? Document Databases vs Relational

MongoDB Fundamentals

Chapter 1 · What is MongoDB? Document Databases vs Relational

🍃 What is MongoDB? Document Databases vs Relational

This course is framed throughout as the NoSQL counterpart to the site's existing MySQL courses — if you've been through those, you already know tables, rows, and normalization; this chapter builds directly on that, contrasting MongoDB's document model against what you already know rather than starting from zero.

The Document Model

Where a relational database like MySQL stores data as rows in tables with a fixed set of columns, MongoDB stores data as documents — JSON-like structures — grouped into collections. The key structural difference: documents in the same collection don't need to share an identical set of fields the way every row in a MySQL table shares the same columns.

Relational Terms vs. MongoDB Terms

MySQL (Relational)

Table → Row → Column, with a Primary Key uniquely identifying each row.

MongoDB (Document)

Collection → Document → Field, with an _id field uniquely identifying each document.

The Same User, Two Ways

// MongoDB: one document, nested data included directly
{
  "_id": ObjectId("64f1a2..."),
  "name": "Alice",
  "email": "alice@example.com",
  "address": { "city": "London", "postcode": "E1 6AN" }
}
            

In MySQL, that same information would typically be normalized across two tables — a users table and a separate addresses table joined by a foreign key (per mysql_advanced_01's normalization chapter). MongoDB often just nests the address directly inside the user document instead.

BSON: Binary JSON

MongoDB doesn't actually store plain-text JSON — it stores BSON (Binary JSON), a binary-encoded format that's more efficient to parse and traverse than text, and supports a few extra types plain JSON doesn't have natively, like real Date objects and MongoDB's own ObjectId type (seen in the _id field above). You interact with it AS IF it were JSON — the binary encoding is an internal storage detail, not something you typically handle directly.

Schema Flexibility: A Blessing and a Trade-off

Because documents in a collection don't need identical fields, adding a new field to some documents doesn't require anything like a MySQL ALTER TABLE migration — you just start including it in new documents. That's a genuine speed advantage during early, fast-moving development. The trade-off: without something enforcing structure, nothing stops two documents in the same collection from representing the same kind of thing in inconsistent, incompatible ways — a problem a fixed relational schema prevents by construction. Chapter 6 covers $jsonSchema validation, MongoDB's opt-in answer to this trade-off.

When MongoDB Genuinely Fits vs. When MySQL Is Still Right

MongoDB Tends to Fit

Rapidly evolving data shapes, deeply nested/hierarchical data that's naturally read and written as one unit, high write-throughput workloads that don't need complex cross-entity joins.

MySQL Still Wins

Strong relational integrity (foreign key constraints), complex multi-table joins and transactional consistency across many entities, stable well-understood schemas that genuinely benefit from enforced structure.

Relational	MongoDB
Table	Collection
Row	Document
Column	Field
Primary Key	`_id`
JOIN	Embedding, or `$lookup` (Chapter 2's advanced-course counterpart)
Schema enforced by the engine	Schema optional by default, opt-in via `$jsonSchema`

💻 Coding Challenges

Challenge 1: Translate the Terms

For each relational term, give its MongoDB equivalent: (a) table, (b) row, (c) primary key, (d) column.

Goal: Practice the vocabulary mapping this chapter introduced before moving further into the course.

→ Solution

Challenge 2: Model a Blog Post as a Document

A relational schema has a posts table and a separate comments table (joined by a foreign key). Sketch how a single blog post, with its comments, might look as one MongoDB document instead.

Goal: Practice translating a normalized relational design into a nested document.

→ Solution

Challenge 3: MongoDB or MySQL?

Recommend MongoDB or MySQL for (a) a product catalog where each product category has wildly different attributes, and (b) a banking system tracking transfers between accounts that must always balance exactly. Justify each choice.

Goal: Practice applying this chapter's "when each fits" section to concrete scenarios.

→ Solution

⚠️ Gotcha: Schema Flexibility Doesn't Mean No Planning Needed

It's tempting to treat MongoDB's lack of an enforced schema as permission to skip designing your data's shape at all. In practice, a collection full of documents that represent "the same kind of thing" in wildly inconsistent ways (one document has email, another has emailAddress, a third nests it under contact.email) becomes just as painful to query reliably as a badly designed relational schema — the difference is MongoDB won't stop you from creating that mess in the first place. Schema flexibility means the database doesn't enforce consistency for you by default; it doesn't mean consistency stops mattering.

🎯 What's Next

The next chapter gets hands-on: Installing MongoDB & mongosh — getting a real MongoDB instance running, connecting with the mongosh shell, and a first look at MongoDB Compass.