Best for
- New features that need tables designed properly the first time
- Schemas where every query needs three joins and a prayer
- Settling normalisation vs pragmatism with reasons instead of taste
What you give it
- What the business needs to record and ask of its data
- Answers to the edge questions it raises (history? deletion? time zones? money?)
What you get back
- A schema proposal: entities, fields, types, keys, constraints, indexes — with the reasoning
- The hard cases decided on paper: history, soft deletion, uniqueness, concurrency
- A migration path if tables already exist, staged and reversible
How it works
- Extracts the real entities and relationships from how the business talks and what it asks of the data.
- Designs for the questions the data must answer — including the reporting ones nobody mentions until later.
- Encodes rules as constraints (keys, uniqueness, checks, foreign keys) so the database refuses bad data.
- Raises the classic traps explicitly: history, time zones, money precision, soft deletes, concurrent edits.
- Proposes indexes from expected query shapes, and a staged migration when changing what exists.
Example
You: Model subscriptions: plans, upgrades mid-cycle, pauses, and finance wants history forever.
Result: A proposal separating the subscription (current state) from its period history (immutable rows), proration decided explicitly, constraints that forbid overlapping periods, and four questions answered on paper — including the one nobody had asked: what happens to a paused subscription at the plan's price change.
Limits — please read
- It proposes; changing a live schema is executed through your approval and migration process.
- Business rules it cannot infer get asked, not assumed — the schema is the business, in table form.
- Extreme-scale physical tuning (partitioning, sharding) is designed when the numbers justify it, not by default.