Tables vs collections thinking in MongoDB - Performance Comparison

Time Complexity: Tables vs collections thinking

O(n)

Understanding Time Complexity

When working with databases, it's important to understand how operations grow as data grows.

Here, we explore how thinking in tables (SQL) compares to collections (MongoDB) affects time complexity.

Scenario Under Consideration

Analyze the time complexity of querying a collection with embedded documents versus joining tables.

// Find all orders with customer info embedded
db.orders.find({"customer.name": "Alice"})

// Versus joining tables in SQL (conceptual)
// SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE customers.name = 'Alice';
    

This snippet shows a MongoDB query searching inside embedded documents compared to a SQL join.

Identify Repeating Operations

Look at what repeats when the database runs the query.

• Primary operation: Scanning documents in the collection to find matches.
• How many times: Once per document in the collection or table.

How Execution Grows With Input

As the number of documents or rows grows, the work to find matches grows too.

Input Size (n)	Approx. Operations
10	10 document checks
100	100 document checks
1000	1000 document checks

Pattern observation: The number of checks grows directly with the number of documents or rows.

Final Time Complexity

Time Complexity: O(n)

This means the time to find data grows in a straight line as the data grows.

Common Mistake

[X] Wrong: "Using embedded documents always makes queries faster than joins."

[OK] Correct: If there is no index, searching inside embedded documents still requires checking many documents, so it can be just as slow as a join scanning many rows.

Interview Connect

Understanding how data structure affects query time helps you explain your design choices clearly and confidently.

Self-Check

"What if we added an index on the embedded field? How would the time complexity change?"

Practice

1. Which of the following best describes a MongoDB collection compared to a SQL table?

easy

A. A collection cannot store nested data.

B. A collection stores flexible documents without fixed columns.

C. A collection is organized strictly in rows and columns.

D. A collection requires fixed columns and strict schema.

Solution

1. Step 1: Understand MongoDB collections

   MongoDB collections store documents that can have different fields and structures.

2. Step 2: Compare with SQL tables

   SQL tables require fixed columns and rows, unlike collections.

3. Final Answer:

   A collection stores flexible documents without fixed columns. -> Option B

4. Quick Check:

   Collections = flexible documents [OK]

Hint: Collections are flexible; tables have fixed columns [OK]

Common Mistakes:

• Thinking collections require fixed columns
• Assuming collections store data in rows and columns
• Believing collections cannot have nested data

2. Which of the following is the correct way to create a collection named users in MongoDB?

easy

A. CREATE TABLE users;

B. CREATE COLLECTION users;

C. db.createCollection('users');

D. db.users.create();

Solution

1. Step 1: Recall MongoDB syntax for creating collections

   MongoDB uses db.createCollection('name') to create collections.

2. Step 2: Check other options

   Options A, B, and D use invalid MongoDB syntax.

3. Final Answer:

   db.createCollection('users'); -> Option C

4. Quick Check:

   Use db.createCollection('name') to create collections [OK]

Hint: Use db.createCollection('name') in MongoDB [OK]

Common Mistakes:

• Using SQL CREATE TABLE syntax in MongoDB
• Trying to call create() on collection object
• Using CREATE COLLECTION which is invalid

3. Given a MongoDB collection products with documents like { name: 'Pen', price: 1.5 } and { name: 'Notebook', price: 3 }, what will db.products.find({ price: { $gt: 2 } }) return?

medium

A. All products with price greater than 2

B. All products with price less than 2

C. All products with price equal to 2

D. Syntax error

Solution

1. Step 1: Understand the query filter

   The filter { price: { $gt: 2 } } selects documents where price is greater than 2.

2. Step 2: Apply filter to example data

   Only the document with price 3 matches; price 1.5 does not.

3. Final Answer:

   All products with price greater than 2 -> Option A

4. Quick Check:

   $gt means greater than [OK]

Hint: Remember $gt means greater than in MongoDB queries [OK]

Common Mistakes:

• Confusing $gt with $lt
• Thinking it returns products with price less than 2
• Assuming syntax error due to $gt usage

4. You tried to insert a document into a MongoDB collection with db.orders.insert({id: 1, item: 'Book'}) but got a deprecation warning. What is the likely cause?

medium

A. The insert method is deprecated; use insertOne or insertMany instead.

B. MongoDB requires documents to have a field named _id, not id.

C. The collection name must be plural, so 'orders' is invalid.

D. Documents cannot have string values in MongoDB.

Solution

1. Step 1: Check MongoDB insert method usage

   The insert() method is deprecated in modern MongoDB versions.

2. Step 2: Use correct insertion methods

   Use insertOne() or insertMany() to insert documents.

3. Final Answer:

   The insert method is deprecated; use insertOne or insertMany instead. -> Option A

4. Quick Check:

   Use insertOne/insertMany, not insert() [OK]

Hint: Use insertOne or insertMany, not insert() [OK]

Common Mistakes:

• Thinking _id field is mandatory to insert
• Believing collection names must be plural
• Assuming string values are invalid in documents

5. You want to store user profiles where each user can have different sets of contact methods (email, phone, social media). Which is the best approach in MongoDB?

hard

A. Create separate tables for each contact method and join them.

B. Store all contact methods as a single string field.

C. Use a fixed schema collection with all possible contact fields, leaving some empty.

D. Use a single collection with flexible documents holding different contact fields.

Solution

1. Step 1: Consider MongoDB's flexible schema

   MongoDB collections allow documents to have different fields, perfect for varying contact methods.

2. Step 2: Compare with relational approach

   Relational tables require joins and fixed schemas, less flexible for this use case.

3. Final Answer:

   Use a single collection with flexible documents holding different contact fields. -> Option D

4. Quick Check:

   Flexible documents fit varying user data best [OK]

Hint: Flexible documents handle varied user data best [OK]

Common Mistakes:

• Trying to use fixed schema for varying data
• Using multiple tables and joins in MongoDB
• Storing complex data as a single string