Event Table vs Status Column Rules
When an event table beats a status column, plus three rules that keep record history answerable.
Syntax
design-and-specify
1 IDENTITY vs EVENTS
A record has an identity; events against it are separate records.
Its summary is a rollup over events, never an overwritten field.
2 TWO LIFECYCLES, TWO FIELDS
Two owners changing one status for two reasons = two state machines.
3 STORE A FACT ONCE
A second stored copy (or a stored summary) is a future disagreement.
4 EXPAND -> SWITCH -> CONTRACT
Three separate changes; contract only once nothing uses the old shape.Example
design-and-specify
SMELL FIX
loans.status overwritten on renew loan_events(kind, occurred_at) + view
tools.status = 'out' | 'retired' lending state + maintenance state
loans.member_email read it from members
orders.total beside order_lines compute the total on read
THE TEST
"What was true last Wednesday?"
- answerable by a query -> shape is right
- answerable only by memory -> an update destroyed it