Start with application questions, not tables

MongoDB data modeling is the process of deciding which facts belong together in a document, which documents belong in a collection, how relationships are represented, and which operations the schema should make efficient.

A relational design often begins by identifying entities and normalizing them into tables. MongoDB supports that style when it fits, but its document model also lets you store data that is commonly read together in a single document.

The key design question is not simply “What entities exist?” It is “How will the application read, write, update, and retain these facts?”

Example application requirements

Imagine an online store. The application must:

1. Display a product page with name, price, images, and category.
2. Display an order with the purchased product names and prices as they were at checkout.
3. Show a customer's recent orders.
4. Update inventory safely when an order is placed.
5. Let an administrator update a product description without rewriting historical orders.

These requirements imply different modeling choices. Product information can live in a products collection, order history in orders, and customer information in customers. An order can embed a snapshot of each purchased item so later product edits do not rewrite history.

Build an access-pattern inventory

Before creating collections, write down the operations and their frequency:

• Query: which fields identify the records?
• Read shape: which related fields are needed together?
• Cardinality: how many related records can exist?
• Update behavior: do related values change together?
• Growth: can an array grow without a known limit?
• Consistency: must multiple records change atomically?
• Retention: are historical values immutable or legally retained?

A schema that makes the most frequent, latency-sensitive reads simple can be better than one that minimizes every duplicate value. However, denormalization has costs: duplicated values must be maintained, documents can grow, and writes can become more complex.

// Product page: one product by its stable identifier
db.products.findOne(
  { _id: ObjectId("65a000000000000000000001") },
  { name: 1, price: 1, images: 1, categoryId: 1 }
);

// Customer order history: latest orders first
db.orders.find(
  { customerId: ObjectId("65a000000000000000000010") },
  { orderNumber: 1, status: 1, total: 1, createdAt: 1 }
).sort({ createdAt: -1 }).limit(20);

// Inventory lookup for checkout
db.inventory.findOne(
  { productId: ObjectId("65a000000000000000000001") },
  { available: 1, reserved: 1 }
);