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