Best for
- A schema design about to become a migration
- Catching the trap that costs a weekend six months from now
- A second opinion on data modelling without a data modeller on staff
What you give it
- The proposed schema (DDL, migration, or ORM models) and what the data means
What you get back
- Findings by severity: the will-hurt-you, the should-fix, the style notes
- Each finding with the concrete failure it prevents — not just 'best practice says'
- The fixed schema proposed alongside, ready to apply
How it works
- Reads the schema against what the data MEANS — the mismatch between description and DDL is where bugs live.
- Hunts the classic traps by checklist: money, time, text-where-enum, missing constraints, cascade surprises, index gaps.
- States each finding as the concrete future failure it prevents, so severity is argued by consequence.
- Returns questions where the schema and the stated rules disagree — the design decision is yours.
Example
You: Review this schema for our invoicing tables before I run the migration.
Result: Two will-hurt-you findings: amounts as floating point (rounding errors compound — integer minor units proposed) and no uniqueness on (account, invoice_number) (duplicates possible under retry — the constraint written). Four should-fixes including naive timestamps and a status column as free text. One question sent back: 'can an invoice exist without a customer? the nullable column says yes, your description says no.'
Limits — please read
- It reviews the design; applying migrations to live data is its own careful process.
- Scale-specific tuning (partitioning) needs your volume numbers — it asks rather than assumes.
- Engine-specific behaviours are checked for the engine you name.