MongoDB Tutorial
- Home
- Introduction
- Installation
- Connection & Databases
- CRUD Operations
- Comparison Operators
- Logical Operators
- Array Operators
- Evaluation Operators
- Update Operators
- Projection & Sorting
- Cursor Methods
- Querying Nested Docs
- Upserts & Indexes
- Aggregation Framework
- Data Modeling
- Validations & Transactions
- Geospatial Queries
- Advanced Indexing
- MongoDB with Next.js
- Best Practices
Data Modeling
Effective data modeling in MongoDB depends on how your application will access and manipulate data. There are two primary patterns: Embedding and Referencing.
Embedding
(Denormalized)
{
_id: 1,
user: "John",
address: {
city: "NYC",
zip: 10001
}
}Referencing
(Normalized)
{
_id: 1,
user: "John",
address_id: 50
}1. Embedding (The "Document" Way)
Data is nested inside the parent document. This is preferred for One-to-One and One-to-Few relationships.
- Pros: Fast reads (single query), data is always together.
- Cons: Document size limit (16MB), potential data duplication.
2. Referencing (The "SQL" Way)
Related data is stored in separate collections and linked via an ID. This is preferred for One-to-Many (Large) and Many-to-Many relationships.
- Pros: No data duplication, avoids 16MB limit issues.
- Cons: Requires multiple queries or `$lookup` (slower).
Guiding Principles
- Model for the UI: Structure your documents according to what you display on your screens.
- Data that changes together should live together: If you always update two pieces of data together, embed them.
- Avoid "N+1" Queries: If referencing forces you to run many separate queries, consider embedding.
Key takeaway: In MongoDB, there is no single "correct" schema. The best schema is the one that provides the best performance for your specific application queries.