Stop 07 · NoSQL DatabasesTopics · 9/12

Data Modeling in NoSQL

In short

In SQL you model the data first and write queries later. In NoSQL you flip it: list your queries first, then shape the data so each one is fast.

Designing your document/collection structure around how your application will query the data — the opposite instinct from SQL's normalize-first approach.

The blob arranges tea, sugar and cups together on a shelf beside the stove.

Think of it like this

Arranging the kitchen by use

If you make chai five times a day, the tea, sugar, cups and strainer live together by the stove, even if there's more sugar on the baking shelf. You arrange by use, not by category. NoSQL modelling is the same: group data by how the app reads it.

Watch it happen

Designing from queries

Screens

Patterns

Embed

Duplicate

Indexes

1/5List the screens: order page, a user's order history, the kitchen's live queue.

The big ideas

What you need to know

Queries first

Write down every screen and API call before designing. The data shape follows from them.

Embed for one-read pages

Data that's always shown together goes in one document, so one query is enough.

Duplication is allowed

Copying a dish name into orders is normal. Just decide how you'll handle the copy if the name changes.

Watch what grows

Anything that grows without limit, like logs or comments, gets its own collection or partition.

See it in code

Walk through the code

1// Access patterns:2// 1. Order page by orderId    2. User's history, newest first3// 3. Kitchen queue by status4 5db.orders.insertOne({6  _id: "ord_1042",7  userId: 7,8  status: "preparing",9  items: [{ dishId: 3, name: "Masala dosa", qty: 2 }],10  placedAt: new Date(),11});12 13db.orders.createIndex({ userId: 1, placedAt: -1 }); // pattern 214db.orders.createIndex({ status: 1, placedAt: 1 });  // pattern 3

1/4Start by writing the access patterns down. Everything below serves these three.

Pattern 1 needs nothing extra, because every collection already has an index on _id.

Save yourself the pain

Common mistakes

Oops

Copying your SQL tables one-to-one into collections.

Do this instead

You'll end up doing joins in code. Start from the screens and design documents for them.

Oops

Duplicating data with no plan for updates.

Do this instead

Decide upfront: is a stale copy fine, like a name on an old order, or must every copy be updated?

Your mission

Model a college fest app

~30 min

Quick check

Orders store a copy of the dish name. Later the dish is renamed. What's the usual approach?

Go deeper

1Design a MongoDB schema for an app by starting from your most common queries.
2Practice deciding what to embed vs reference for a one-to-many relationship.
3Learn that NoSQL modeling often means intentional, controlled duplication.