Data Modeling Lab
Turn product requirements and access patterns into a correct, maintainable, performant data model. Not an ER-diagram editor: you start from requirements, discover entities, wire relationships and constraints, design from access patterns, plan indexes with their costs, and end with a senior-style schema review.
- Requirements→
- Entities→
- Relationships→
- Constraints→
- Access Patterns→
- Normalization→
- Indexes→
- Schema→
- Queries→
- Review
What are the core entities?
Add them one at a time. For each candidate ask: is it an entity (has identity and a lifecycle), an attribute (describes an entity), or an event (something that happened)?
Modeling concepts, four altitudes deep
Keys, time, money, lifecycle, tenancy, evolution — each explained beginner → internals, with the internals level linking into Database Internals.
A natural key is a value that already identifies the thing in the real world — an email, an ISBN, a country code. A surrogate key is a value the database invents just to be an id, like an auto-incrementing number, that means nothing outside the table.
An integer id counts up: 1, 2, 3. A UUID is a 128-bit value that looks random, so two machines can each mint ids without asking a central counter and (almost) never collide. UUIDs are bigger and unordered; integers are small and ordered.
Sometimes no single column identifies a row, but a pair does. A junction table linking students to courses is uniquely identified by (student_id, course_id) — that pair is the primary key.
The primary key guarantees each row is unique and gives every other table a handle to reference. But it also quietly decides how rows are stored and how fast joins and lookups run.