Stage 2 · Lesson 3 of 11
Data modelling and normalisation
Now design your own , the set of tables and how they connect. Start from the nouns in the problem, such as customers, orders and products, and how they relate. One to many (one customer, many orders) becomes a on the "many" side.
Many to many (orders and products) needs a table such as order_items. means storing each fact once. A customer's email lives in the customers table, not copied onto every order, so an update changes one row.
Third normal form is enough for most backends. You denormalise, copying data on purpose, only to fix a measured read problem.
Common trapThe trap runs the other way too: keeping the price only on the product means a price change rewrites history, so each order line should record the price actually paid.
A question to check yourself, an AI practice session and 1 cheat sheet entry come with the full roadmap. Unlock
Resources for this stage
Start with· follow one of these
- CoursePaidGrokking Relational Database Design and Modeling
Design Gurus · Intermediate · $98 one-time
The modelling and normalisation decisions that stay with a codebase for years
- CourseFreeCS50's Introduction to Databases with SQL
Harvard University · Beginner
Free course from querying through schema design, indexes, transactions and scaling
Practise
Also worth your time
- Database Indexing Explained: B-Tree, Hash, Bitmap, R-Tree, and When to Use Each (opens in a new tab)Read
B-tree and composite indexes, plus the leftmost-prefix rule that trips people up
What sits under your queries: storage engines, transactions and isolation levels