One-to-many relationship
One parent record can have several child records, like one customer with many orders; the child stores the parent's id.
See it
What it is
A one-to-many relationship means one row on the parent side can be linked to several rows on the child side, while each child points back to one parent. One customer has many orders; each order belongs to one customer. In a relational database, the foreign key lives on the many side, so orders gets customer_id rather than customers getting an array of order ids.
Reach for it when the child has its own identity and lifecycle: posts under an author, line items under an order, comments under an issue. Make the foreign key NOT NULL when every child must have a parent, nullable when the relationship is genuinely optional, and choose the delete rule deliberately.
Gotcha: joining the parent to its children returns one parent row per matching child. That fan-out can duplicate parent totals and break pagination. Aggregate the children before the join when you need one row per parent, and index the child's foreign-key column so fetching one parent's children does not scan the entire child table. ORMs draw the same line: Django gives you select_related for the join up to a parent and prefetch_related, a second query, for the list of children, because a join is the wrong shape going down.
Ask AI for it
Model this as a PostgreSQL one-to-many relationship. Put the parent key on the child table as a typed customer_id-style column, add a FOREIGN KEY REFERENCES parent(id), and make it NOT NULL unless an orphaned child is a valid state. Choose ON DELETE RESTRICT by default, CASCADE only when the child has no meaning without the parent, or SET NULL for a real optional link. Create a B-tree index on the child foreign key, show the CREATE TABLE and CREATE INDEX statements, and include a query that loads one parent with its children without double-counting parent aggregates.