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.
1.5.1The shape of your data is called a schema
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.
1.5.2List your entities and their key fields
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.
1.5.3Draw the relationships between them
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. Sketched out, a shop's model nests like this:
User
has many: Order
has many: LineItem
references: Product
Each indent is a "belongs to": a LineItem sits under one Order, which sits under one User. It reads unambiguously to both you and your agent, no diagram tool needed.
1.5.4Keep it a sketch, not a database
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.
This prompt drafts the sketch from your app:
Act as a senior engineer sketching my data model. From my
app, list the entities (the things it stores), each with
its key fields, and state every relationship as "has many"
or "belongs to." Keep it a plain sketch, not SQL and not a
real database yet.
My app, and what it needs to remember:
Do this now: paste the prompt and let your agent draft the entity sketch, then check the relationships match how you picture your app.
