Your app stores things: people, their stuff, the records of what they did. Code changes cheaply, but the shape of that stored data does not, because once real users have created it, you cannot rename or reorganize it without touching everything they made. So you sketch that shape first, on paper, before a line of code. This chapter gets you a plain data model: the things you store, what each one holds, and how they connect.
The shape of your data is called a schema1.4.1
A schema is the plan for what your app stores, separate from the place it gets stored (an earlier chapter covered what a database is). You are drawing the plan now, not choosing the storage yet.
The plan has two parts: the things you keep, and the links between them. Get both right on paper and the actual build is mostly transcription.
List your entities and their key fields1.4.2
An entity is one kind of thing you store, like a User or an Order. A field is one piece of information an entity holds, like a user's email or an order's total.
Name each entity as a singular noun, then list only its key fields: the ones the app genuinely needs, not every detail you can imagine. Write it as a plain table.
| Entity | Key fields |
|---|---|
User | name, email, password |
Order | total, status, createdAt |
If you cannot name an entity as a single noun, it is probably two entities hiding in one.
Draw the relationships between them1.4.3
A relationship is how two entities connect. Most connections are one-to-many: one entity owns many of another, and each of those belongs to exactly one owner.
A User has many Orders, and each Order belongs to one User. That is one-to-many. When both sides have many (a Post has many Tags and a Tag covers many Posts), that is many-to-many, and you note it as such.
State every relationship in that plain "has many" and "belongs to" form. It reads unambiguously to both you and your agent, with no diagram needed.
Example: A
Userhas manyOrders. AnOrderbelongs to oneUserand has manyLineItems. ALineItembelongs to oneOrderand references oneProduct.
Keep it a sketch, not a database1.4.4
Resist writing SQL, picking a product, or adding fields for features you have not scoped. The model is a thinking tool, and every field you add now is one more thing to keep true later.
A later chapter turns this sketch into real tables. Right now you only need it clear enough that someone else could read it and know what your app remembers.
Do this now: list every entity, write its key fields in a table, and state each relationship as "has many" or "belongs to."
