One-to-many referencing pattern in MongoDB - Step-by-Step Execution

Concept Flow - One-to-many referencing pattern

Parent Document Created

↓

Child Documents Created

↓

Child Documents store Parent _id

↓

Query Parent

↓

Query Child Documents by Parent _id

↓

Combine Parent with Children

↓

Result

Create a parent document and multiple child documents that reference the parent's ID. Query parent and then find all children linked by that ID.

Execution Sample

MongoDB

db.authors.insertOne({_id: 1, name: 'Alice'})
db.books.insertMany([
  {title: 'Book A', author_id: 1},
  {title: 'Book B', author_id: 1}
])
db.authors.findOne({_id: 1})
db.books.find({author_id: 1})

Insert one author and two books referencing that author, then query the author and their books.

Execution Table

Step	Action	Input/Query	Result/Output
1	Insert parent document	{_id: 1, name: 'Alice'}	Author document created with _id 1
2	Insert child documents	[{title: 'Book A', author_id: 1}, {title: 'Book B', author_id: 1}]	Two book documents created referencing author_id 1
3	Query parent document	{_id: 1}	{_id: 1, name: 'Alice'}
4	Query child documents by parent _id	{author_id: 1}	[{title: 'Book A', author_id: 1}, {title: 'Book B', author_id: 1}]
5	Combine parent and children	Parent + Children	{author: {_id:1, name:'Alice'}, books: [{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]}
6	End	No more steps	Execution complete

💡 All documents inserted and queried successfully, referencing pattern established.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
authors collection	empty	[{_id:1, name:'Alice'}]	[{_id:1, name:'Alice'}]	[{_id:1, name:'Alice'}]	[{_id:1, name:'Alice'}]	[{_id:1, name:'Alice'}]
books collection	empty	empty	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]
queried parent	none	none	none	{_id:1, name:'Alice'}	{_id:1, name:'Alice'}	{_id:1, name:'Alice'}
queried children	none	none	none	none	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]	[{title:'Book A', author_id:1}, {title:'Book B', author_id:1}]

Key Moments - 3 Insights

Why do child documents store the parent's _id instead of embedding the whole parent document?

Storing only the parent's _id keeps child documents smaller and avoids duplication. This referencing allows easy updates to the parent without changing all children, as shown in execution_table steps 2 and 4.

How do we find all child documents related to a specific parent?

We query the child collection filtering by the parent's _id stored in the child documents (execution_table step 4). This returns all children linked to that parent.

What happens if the parent document is deleted but child documents still reference its _id?

Child documents will reference a non-existent parent, causing broken links. This is why application logic or database constraints should handle such cases, though MongoDB does not enforce it automatically.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what does the query return?

A All books with author_id 1

B The author document with _id 1

C All authors in the database

D No documents

💡 Hint

Check the 'Input/Query' and 'Result/Output' columns at step 4 in execution_table.

According to variable_tracker, what is the state of the books collection after step 2?

A Empty

B Contains two book documents referencing author_id 1

C Contains one book document

D Contains author documents

💡 Hint

Look at the 'books collection' row under 'After Step 2' in variable_tracker.

If we did not store author_id in the books, what would be the impact on querying children by parent?

A We could still easily find all books by author_id

B We would need to embed the entire author document in each book

C We could not link books to authors by a simple query

D No impact, queries remain the same

💡 Hint

Refer to key_moments about why child documents store parent's _id.

Concept Snapshot

One-to-many referencing in MongoDB:
- Parent document has unique _id.
- Child documents store parent's _id as a reference.
- Query parent by _id.
- Query children by author_id (parent's _id).
- Keeps data normalized and avoids duplication.

Full Transcript

This visual execution shows how one-to-many referencing works in MongoDB. First, a parent document (author) is inserted with a unique _id. Then multiple child documents (books) are inserted, each storing the parent's _id in a field (author_id). When querying, we first find the parent document by its _id, then find all child documents that reference this _id. This pattern keeps data normalized, avoids duplication, and allows easy updates to the parent without changing children. The execution table traces each step: inserting documents, querying parent and children, and combining results. The variable tracker shows how collections and query results change after each step. Key moments clarify why children store only the parent's _id and how queries link them. The quiz tests understanding of these steps and the importance of referencing. This pattern is common in MongoDB for modeling one-to-many relationships.

Practice

1. What is the main purpose of the one-to-many referencing pattern in MongoDB?

easy

A. To create a backup of documents automatically

B. To store all related data inside a single document

C. To link one document to many related documents using their IDs

D. To encrypt documents for security

Solution

1. Step 1: Understand one-to-many referencing

   It connects one document to many others by storing their IDs, not embedding all data.

2. Step 2: Compare options

   Only To link one document to many related documents using their IDs describes linking documents by IDs, which is the core of one-to-many referencing.

3. Final Answer:

   To link one document to many related documents using their IDs -> Option C

4. Quick Check:

   One-to-many referencing = linking documents by IDs [OK]

Hint: One-to-many means one document points to many IDs [OK]

Common Mistakes:

• Thinking all data is stored inside one document
• Confusing referencing with embedding
• Assuming it creates backups automatically

2. Which of the following is the correct way to reference many comments in a post document using one-to-many referencing in MongoDB?

easy

A. { _id: 1, title: 'Post', comments: [ObjectId('abc123'), ObjectId('def456')] }

B. { _id: 1, title: 'Post', comments: { text: 'Nice post!' } }

C. { _id: 1, title: 'Post', comments: 'This is a comment' }

D. { _id: 1, title: 'Post', comments: ObjectId('abc123') }

Solution

1. Step 1: Identify referencing format

   One-to-many referencing stores an array of ObjectIds pointing to related documents.

2. Step 2: Check each option

   { _id: 1, title: 'Post', comments: [ObjectId('abc123'), ObjectId('def456')] } uses an array of ObjectIds, which is correct. Others embed data or use a single ID incorrectly.

3. Final Answer:

   { _id: 1, title: 'Post', comments: [ObjectId('abc123'), ObjectId('def456')] } -> Option A

4. Quick Check:

   Array of ObjectIds = correct referencing [OK]

Hint: Use array of ObjectIds to reference many documents [OK]

Common Mistakes:

• Embedding comment text instead of IDs
• Using a single ObjectId for many comments
• Storing comments as plain strings

3. Given these two collections:
posts: [{ _id: 1, title: 'Hello', comments: [101, 102] }]
comments: [{ _id: 101, text: 'Nice!' }, { _id: 102, text: 'Great!' }]
What will be the result of this query to find comments for post with _id 1?
db.comments.find({ _id: { $in: db.posts.findOne({ _id: 1 }).comments } })

medium

A. [] (empty array)

B. [{ _id: 1, title: 'Hello', comments: [101, 102] }]

C. SyntaxError due to nested query

D. [{ _id: 101, text: 'Nice!' }, { _id: 102, text: 'Great!' }]

Solution

1. Step 1: Understand the query

   The inner findOne gets the comments array [101, 102] from post _id 1.

2. Step 2: Use $in to find matching comments

   The outer find returns comments with _id in [101, 102], so both comment documents are returned.

3. Final Answer:

   [{ _id: 101, text: 'Nice!' }, { _id: 102, text: 'Great!' }] -> Option D

4. Quick Check:

   Find comments by IDs in post = matching comment docs [OK]

Hint: Use $in with IDs array to get related documents [OK]

Common Mistakes:

• Expecting post document instead of comments
• Thinking nested query causes syntax error
• Getting empty result by mistake

4. You have this post document:
{ _id: 1, title: 'Test', comments: ['abc', 'def'] }
But when you run db.comments.find({ _id: { $in: post.comments } }), it returns no results. What is the most likely problem?

medium

A. ObjectIds in post.comments are strings, not ObjectId type

B. The comments collection has no documents with those ObjectIds

C. The query syntax is incorrect for $in operator

D. The post document is missing the comments field

Solution

1. Step 1: Check data types of referenced IDs

   If post.comments contains strings instead of ObjectId objects, the query won't match.

2. Step 2: Confirm query correctness

   The query syntax is correct, so the mismatch is likely due to type difference.

3. Final Answer:

   ObjectIds in post.comments are strings, not ObjectId type -> Option A

4. Quick Check:

   Type mismatch in IDs causes no matches [OK]

Hint: Ensure referenced IDs are ObjectId type, not strings [OK]

Common Mistakes:

• Assuming empty results mean syntax error
• Ignoring data type differences
• Thinking missing field causes this error

5. You want to design a blog system with users, posts, and comments. Each user can write many posts, and each post can have many comments. Using one-to-many referencing, which is the best way to organize references?

hard

A. comments store userId; posts store arrays of commentIds

B. posts store userId; comments store postId; users do not store references

C. users embed all posts; posts embed all comments

D. users store arrays of postIds; posts store arrays of commentIds

Solution

1. Step 1: Understand one-to-many referencing best practice

   Usually, the 'many' side stores the reference to the 'one' side to avoid large arrays.

2. Step 2: Apply to blog system

   Posts store userId (one user, many posts), comments store postId (one post, many comments), users don't store arrays.

3. Final Answer:

   posts store userId; comments store postId; users do not store references -> Option B

4. Quick Check:

   Many side stores reference to one side [OK]

Hint: Store reference on 'many' side to 'one' side document [OK]

Common Mistakes:

• Embedding all posts or comments inside users or posts
• Storing large arrays on 'one' side documents
• Confusing which side stores the reference