Mongo DB Flashcards
Why document database?
It stores data in a flexible, JSON-like format known as BSON (Binary JSON). Unlike relational databases that use tables and rows, MongoDB organizes data into documents within collections. Each document is a self-contained unit that can hold key-value pairs, arrays, and even nested objects, making it highly flexible and schema-less.
Saving to DB
client = MongoClient(“mongodb://localhost:27017/”)
db = client[“myDatabase”]
collection = db[“myCollection”]
document = {“name”: “John”, “age”: 30, “city”: “New York”}
collection.insert_one(document)
Fetch from DB
client = MongoClient(“mongodb://localhost:27017/”)
db = client[“myDatabase”]
collection = db[“myCollection”]
Read all documents
for doc in collection.find():
print(doc)
Read with a filter
doc = collection.find_one({“name”: “John”})
print(doc)
Organization
In MongoDB, data is organized in a hierarchical and flexible structure rather than rigid tables and rows like relational databases
📂 Database → A logical container for collections (like a schema in SQL).
📁 Collection → A group of related documents (like a table in SQL).
📜 Document → A JSON-like BSON (Binary JSON) object storing key-value pairs (like a row in SQL).
Field → A key-value pair inside a document (like a column in SQL).
Schemaless
Schema-less → Documents in the same collection can have different structures.
Nested Documents
Embedded/Nested Documents → Related data is stored together in a single document.
Indexing
Indexing for Fast Access → Indexes improve query performance.
Single-Field Index
Indexes a single field, improving search performance.
db.users.createIndex({ name: 1 }) # Ascending order
db.users.find({ name: “Alice” })
Compound Index
Indexes multiple fields for efficient searches involving both fields.
db.users.createIndex({ name: 1, age: -1 }) # First sort by name, then by age descending
db.users.find({ name: “Alice”, age: 25 })
Types of Indexes
Single Field
Compound Field
Multikey Index - Indexing array based field
Text Index - Full text search on a field
GeoSpatial Index - Used for queries on location-based data.
List Indexes
db.users.getIndexes()
Drop Indexes
db.users.dropIndex(“name_1”)
Use Cases
Hierarchical & Nested Data - User Orders, Social Media Posts
{
“_id”: 101,
“customer”: “John Doe”,
“items”: [
{ “product”: “Laptop”, “price”: 1200, “quantity”: 1 },
{ “product”: “Mouse”, “price”: 25, “quantity”: 2 }
],
“status”: “shipped”
}
Session Data
✔ Ideal for: High-speed session storage
✔ Example: Authentication tokens, shopping carts
{
“session_id”: “xyz123”,
“user_id”: 1001,
“last_active”: “2024-03-05T12:00:00Z”
}
Why
Embedded documents eliminate costly JOIN operations.
When not to use
Highly relational data (e.g., banking transactions, ERP systems) – Joins are required here.
Heavy ACID compliance needs (MongoDB provides transactions but not as strong as SQL)
Fixed-schema datasets (Better suited for RDBMS like MySQL, PostgreSQL)
Highly Relational Data - What is
Highly relational data consists of interconnected entities where strong data integrity, consistency, and ACID compliance are critical. This type of data is best suited for relational databases (RDBMS) like MySQL, PostgreSQL, or Oracle because they enforce foreign keys, normalization, and transactions.
Example banking data
A bank manages customers, accounts, transactions, and branches. Each entity has strong relationships, and data integrity is crucial.
MongoDB does not support traditional SQL-style joins, making complex queries inefficient.
Since MongoDB stores denormalized data (embedding), updates can be redundant and inconsistent.
Ex - If a customer’s email changes, you must update multiple documents.
Multi Document Transactions
MongoDB supports transactions (starting from v4.0), but they are not as efficient as SQL databases.
Loosely Related Data vs Highly Related Data
While MongoDB is not the best for highly relational data, it can work for loosely related data by: ✔ Embedding documents (one-to-many, when reads are frequent).
✔ Using references ($lookup) for many-to-many relationships (at a performance cost).
✔ Denormalization for read-heavy workloads (faster reads but more storage).
Joins in Mongodb
MongoDB does not support traditional SQL joins, but it provides an alternative using the $lookup aggregation stage to join documents from multiple collections.
❌ Slower than SQL Joins → MongoDB is not optimized for cross-collection queries.
❌ Not Suitable for Deeply Nested Joins → Performance drops with multiple $lookup stages.
❌ No Index Support for $lookup Queries → Lookups scan the entire foreign collection.
❌ One-to-Many is Limited → Large referenced datasets may return huge arrays, affecting performance.
