Document Schema Design

Document schema design is crucial in MongoDB as it determines how data is stored, accessed, and queried. MongoDB’s flexible schema allows for dynamic changes but requires thoughtful design to optimize performance and scalability.

Key Considerations

  • Data Access Patterns: Design your schema based on how your application will query the data.
  • Data Size and Frequency: Consider the size of documents and the frequency of read/write operations.
  • Indexing Needs: Plan for indexes based on query requirements to enhance performance.

Embedding vs. Referencing

Embedding

  • Description: Embedding involves nesting documents within other documents. This approach is suitable for related data that is often accessed together.
  • Advantages:
    • Faster read operations as all related data is stored in a single document.
    • Simpler data model for hierarchical or nested data.
  • Disadvantages:
    • Document size can grow significantly if nested data is large.
    • Updates to embedded data require modification of the parent document.
  • Example: 
      {
  _id: 1,
  name: "John Doe",
  address: {
    street: "123 Main St",
    city: "Anytown",
    zip: "12345"
  }
}

Referencing

  • Description: Referencing involves storing references (e.g., IDs) to related documents in separate collections. This approach is suitable for data that is often queried independently.

  • Advantages:

    • Reduces document size and duplication of data.
    • Easier to manage and update large or frequently changing data.

  • Disadvantages:

    • Requires multiple queries or joins (using $lookup) to retrieve related data.
    • More complex data model with potential performance trade-offs.

  • Example:

      // User document
{
  _id: 1,
  name: "John Doe",
  addressId: 101
}

// Address document
{
  _id: 101,
  street: "123 Main St",
  city: "Anytown",
  zip: "12345"
}

Data Denormalization and Normalization

Data Denormalization

  • Description: Involves combining related data into a single document to reduce the number of queries required.
  • Use Cases: Optimizes read performance for frequently accessed data, reduces the need for joins.
  • Trade-offs: Increased document size and potential data redundancy.

Data Normalization

  • Description: Involves separating data into multiple documents to reduce redundancy and improve data integrity.
  • Use Cases: Simplifies updates and maintains consistency across related data.
  • Trade-offs: Potentially slower reads due to the need for multiple queries or joins.

Use Cases for Different Data Models

When to Use Embedding

  • Hierarchical Data: When dealing with hierarchical data structures or nested objects (e.g., user profiles with multiple addresses).
  • Frequently Accessed Together: When related data is often accessed together in a single query.

When to Use Referencing

  • Large or Frequently Updated Data: When dealing with large documents or data that changes frequently (e.g., product catalog with reviews).
  • Many-to-Many Relationships: When managing relationships between entities (e.g., students and courses).