Skip to content
DiagramDock

ER diagram guide

Tables, keys, cardinality, and the modelling decisions worth arguing about.

An ER diagram is worth drawing before the migration, not after. Moving a box costs nothing; moving a column in production costs a maintenance window.

Cardinality comes from the keys

You do not have to decide cardinality separately from the schema — the schema already says it. A foreign key that is itself unique implies one-to-one. A plain foreign key implies one-to-many. A table that is nothing but two foreign keys is a join table, so many-to-many.

A blog schema with post_tag as a real join table rather than a hand-waved many-to-many.
A blog schema with post_tag as a real join table rather than a hand-waved many-to-many.Open this template

Decisions the diagram exposes

  • Whether an associative table carries data of its own — an enrolment has a term and a grade, so it is a table, not a link
  • Whether historical values need snapshotting — order lines store the price paid, not the current price
  • Whether an entity is the thing or an instance of the thing — a library lends a copy, not a title

Templates