database-designlisted

# Database Design A schema designed from the entity-relationship diagram alone is designed from the wrong input. The ERD describes the domain; the actual read/write access pattern is what should drive the schema, indexing, and technology choice. ## Step 1 — Access pattern first Before drawing tables, list the actual queries this schema needs to serve well: what's read together, what's written together, what's queried by range vs. exact match, what needs to be fast versus what can be slow. Design from this list, not from the domain model in isolation. ## Step 2 — Normalization vs. denormalization, with a stated reason Every denormalized table needs an explicit reason tied to Step 1 (a specific hot query that needs the data pre-joined). Denormalization with no stated reason is pure inconsistency risk with no offsetting benefit — flag it as a problem, not a style choice, when found without justification. ## Step 3 — SQL vs. NoSQL as a real trade-off Decide based on the actual consistency requirement (strong vs. eventual — state this explicitly) and query flexibility need from Step 1, not team familiarity or what's trending. A document store chosen for a workload that's actually relational (many cross-entity joins in the access pattern) creates exactly the joins-in-application-code problem the choice was supposed to avoid. ## Step 4 — Indexing tied to the access pattern Every index has a write-cost — only add one that serves a query actually in the Step 1 list. Check spe