Data Model Review
By Reese Martinez · Published · Updated
Checks a database design for the entities, relationships, constraints and indexes it needs, judged against the queries the application actually runs.
Prompt template
## Data Model Review Review this data model against how it will be used. - Schema or model: [textarea: Paste tables or collections with fields and types] - Database: [dropdown: PostgreSQL, MySQL, Firestore, MongoDB, SQLite, Other] - Main access patterns: [textarea: The reads and writes the app does most with rough volume] - Expected size: [text: Rows or documents in a year] - Rules the data must obey: [textarea: Uniqueness or required fields or allowed states] - Known pain: [textarea: Slow queries or awkward joins or duplicated data] Start from the access patterns, not the schema: list each query or write and the fields it filters, sorts and joins on. Then check the entities and relationships: one fact stored in one place, many-to-many relations through a link table or array, and clear ownership of each record. Check constraints: primary keys, foreign keys, unique and not-null rules, check constraints for allowed states, and what happens on delete. Review types and naming for traps such as money in floats, time zones, free-text status fields, and nullable columns that carry meaning. Propose indexes for each access pattern, show the composite order and say which existing indexes are unused or redundant. For document databases, judge embedding against referencing by read and update frequency. Finish with a prioritised list of changes, a migration order that avoids downtime, and the risks of each.