Databases and Data Models
See why a small feature may require a larger change to the model. · Technical Fluency · Lesson 21 · 3 min
Databases and Data Models · 3 min
Situation
“Let one booking include several guests.”
A booking product currently stores a single guest ID on each booking. Design adds an “Add guest” button. Engineering says the change affects the data model.
The system was built around one relationship. Supporting several guests changes more than the number of fields on a screen.
Mental model
Model the things and their relationships.
In a relational database, tables organize records with named columns. IDs identify records. Relationships connect entities such as customers, bookings, and payments.
A data model expresses assumptions about the product: whether a booking has one owner, whether a payment can cover several bookings, and whether guests can belong to multiple groups.
Example
A relationship can need its own record.
A separate booking-guests table could connect booking IDs to guest IDs. That relationship may also need invitation status, attendance, and permissions.
This is an illustrative option, not a prescription. The engineering discussion should surface which facts belong to the booking, the person, and their relationship.
Failure case
Old records do not magically fit.
If every existing booking has one guest, a migration needs a rule for creating the new relationships. Reports, exports, notifications, and permissions may still assume one guest.
Ask which systems read the old shape and how historical data will be interpreted. A new screen can work while an old report silently double-counts bookings.
PM decision
Clarify the business rules first.
Can one guest cancel the whole booking? Who receives refunds? Does removing a guest change the price? Can an invited guest see other guests' information?
These decisions guide the model. Hand engineering a coherent set of rules and states, then collaborate on a design that supports them.
Remember this
A data model is a set of product assumptions.
When a feature changes relationships or ownership, expect effects beyond the UI. Clarifying those assumptions early prevents rework and inconsistent behavior.