📖 Scenario: You are building a simple online bookstore database using MongoDB. You want to store information about books and their authors. Each book has a title and an author. Each author has a name and a country.Sometimes authors write many books, and sometimes books have only one author. You want to decide whether to embed author details inside each book document or to reference authors separately.
🎯 Goal: Build two collections: authors and books. First, create author documents. Then create book documents that reference authors by their _id. This will help you understand referencing in MongoDB.
📋 What You'll Learn
Create an authors collection with two authors: 'Jane Austen' from 'UK' and 'Mark Twain' from 'USA'.
Create a books collection with two books: 'Pride and Prejudice' by Jane Austen and 'Adventures of Huckleberry Finn' by Mark Twain.
Use referencing by storing the author's _id inside each book document.
Do not embed author details inside the book documents.
💡 Why This Matters
🌍 Real World
Online bookstores and many other applications use referencing in MongoDB to keep data organized and avoid duplication.
💼 Career
Understanding embedding vs referencing is essential for designing efficient MongoDB databases in software development and data engineering roles.
Progress0 / 4 steps
1
Create the authors collection with two authors
Create a variable called authors that is a list of two dictionaries. The first dictionary should have 'name': 'Jane Austen' and 'country': 'UK'. The second dictionary should have 'name': 'Mark Twain' and 'country': 'USA'.
MongoDB
Hint
Think of authors as a list of small address cards, each with a name and country.
2
Create a mapping from author names to their IDs
Create a variable called author_ids that is a dictionary mapping author names to unique string IDs. Use 'Jane Austen' mapped to 'a1' and 'Mark Twain' mapped to 'a2'.
MongoDB
Hint
This dictionary helps you link books to authors by ID instead of repeating full author details.
3
Create the books collection referencing authors by ID
Create a variable called books that is a list of two dictionaries. The first dictionary should have 'title': 'Pride and Prejudice' and 'author_id': 'a1'. The second dictionary should have 'title': 'Adventures of Huckleberry Finn' and 'author_id': 'a2'.
MongoDB
Hint
Each book stores only the author_id to link to the author, not the full author details.
4
Add the final step to simulate inserting documents into MongoDB
Create a variable called db that is an empty dictionary. Then add the authors list to db under the key 'authors' and the books list under the key 'books'.
MongoDB
Hint
This simulates how MongoDB stores collections inside a database object.
Practice
(1/5)
1. Which scenario is best suited for embedding related data in MongoDB?
easy
A. Storing a user's profile and their list of addresses when addresses are few and rarely shared.
B. Storing product details and linking to multiple categories by ID.
C. Storing large documents that are frequently updated independently.
D. Storing shared tags used by many blog posts.
Solution
Step 1: Understand embedding use case
Embedding is best when related data is small and tightly coupled, like a user's addresses.
Step 2: Analyze options for embedding
Storing a user's profile and their list of addresses when addresses are few and rarely shared fits because addresses are few and not shared, so embedding improves read speed.
Final Answer:
Storing a user's profile and their list of addresses when addresses are few and rarely shared. -> Option A
Quick Check:
Embedding = small, tightly related data [OK]
Hint: Embed when data is small and tightly linked [OK]
Common Mistakes:
Embedding large or shared data causing duplication
Referencing small, simple data unnecessarily
2. Which of the following is the correct way to reference a document in MongoDB?
easy
A. { "author_id": ObjectId("507f1f77bcf86cd799439011") }
B. { "author": { "$ref": "users", "$id": ObjectId("507f1f77bcf86cd799439011") } }
C. { "author": ObjectId("507f1f77bcf86cd799439011") }
D. { "author": "507f1f77bcf86cd799439011" }
Solution
Step 1: Identify referencing syntax
Referencing stores the related document's ID as a field, usually named with _id suffix.
Step 2: Check options for correct ID reference
{ "author_id": ObjectId("507f1f77bcf86cd799439011") } correctly stores the ObjectId with a clear field name author_id.
Final Answer:
{ "author_id": ObjectId("507f1f77bcf86cd799439011") } -> Option A
Quick Check:
Reference = store related document's ID [OK]
Hint: Reference by storing ObjectId in a field ending with _id [OK]
Common Mistakes:
Using string instead of ObjectId for references
Using $ref and $id without DBRef context
Embedding full document instead of referencing
3. Given a MongoDB collection orders where each order embeds a small array of items, what is the expected result of querying an order by ID?
medium
A. Only the order document without any items data.
B. An error because embedded arrays cannot be queried.
C. The order document with all embedded items included in the result.
D. A list of item documents from a separate collection.
Solution
Step 1: Understand embedding query behavior
When data is embedded, querying the parent document returns all embedded data inside it.
Step 2: Analyze query result for embedded items
Querying by order ID returns the order document including the embedded items array.
Final Answer:
The order document with all embedded items included in the result. -> Option C
Quick Check:
Embedding returns full embedded data [OK]
Hint: Embedded data returns inside parent document query [OK]
Common Mistakes:
Expecting separate documents for embedded data
Thinking embedded arrays cause query errors
Confusing referencing with embedding results
4. You have a MongoDB schema where user documents embed an array of posts. You notice performance issues when updating posts frequently. What is the likely cause and fix?
medium
A. Indexing embedded arrays causes slow updates; remove indexes.
B. Referencing posts causes slow updates; embed posts instead.
C. Using ObjectId for posts causes slow updates; use strings instead.
D. Embedding large arrays causes slow updates; switch to referencing posts separately.
Solution
Step 1: Identify embedding impact on updates
Embedding large or frequently updated arrays causes the whole document to be rewritten, slowing updates.
Step 2: Choose referencing to improve update performance
Referencing posts separately allows updating posts without rewriting the entire user document.
Final Answer:
Embedding large arrays causes slow updates; switch to referencing posts separately. -> Option D
Quick Check:
Large/frequent updates = use referencing [OK]
Hint: Large, frequently updated data? Use referencing [OK]
Common Mistakes:
Embedding large arrays despite frequent updates
Ignoring update performance impact
Misunderstanding ObjectId role in updates
5. You are designing a MongoDB schema for a blogging platform. Each blog post has many comments, and comments can be edited or deleted independently. Also, comments can be very large in number. What is the best design choice?
hard
A. Embed all comments inside each blog post document.
B. Reference comments in a separate collection linked by post ID.
C. Embed only the first 10 comments and reference the rest.
D. Store comments as a JSON string inside the blog post.
Solution
Step 1: Analyze comment characteristics
Comments are numerous, large, and updated independently, so embedding would cause large documents and slow updates.
Step 2: Choose referencing for scalability and independent updates
Referencing comments in a separate collection allows efficient updates and avoids large blog post documents.
Final Answer:
Reference comments in a separate collection linked by post ID. -> Option B