What this prompt does
This prompt converts business requirements into a concrete [database_type] schema for your [domain]. You hand it [requirements] in plain language, and it returns a Mermaid ER diagram, full table definitions with columns and constraints, normalization to your chosen [normal_form], foreign keys with cascade rules, and indexes targeted at your [query_patterns]. It rounds out the design with check constraints, a soft-versus-hard delete strategy, audit columns, and migration scripts in [migration_tool].
The structure works because it front-loads the decisions that are expensive to change later. By asking for normalization trade-offs, a partitioning strategy for [large_table], and a performance analysis of your top [query_count] queries, it pushes you to think about scale before you write application code. Getting tables, constraints, and indexes right up front is far cheaper than re-architecting a schema after launch. It also asks for a soft-versus-hard delete strategy, audit columns like created_at and updated_at, foreign key cascade rules, and check constraints, so the schema encodes business rules at the database level instead of leaving them to application code that can drift or be bypassed. Seed data for development rounds it out so a new contributor can spin up a realistic environment quickly.
When to use it
- You are starting a new application and want a solid schema before writing any backend logic.
- You have rough
[requirements]and need them translated into normalized tables and relationships. - You expect a
[large_table]to grow into millions of rows and need a partitioning strategy early. - You want migration scripts generated in
[migration_tool]rather than hand-writing them. - You need a visual ER diagram to align stakeholders or document the data model.
- You want index recommendations tied to specific
[query_patterns]instead of guessing.
Example output
Expect a layered deliverable: a Mermaid ER diagram first, followed by CREATE TABLE-style definitions with types and constraints, a normalization discussion explaining where you stay at [normal_form] and where you denormalize, foreign key and cascade rules, an index list mapped to your [query_patterns], and [migration_tool] migration files. Seed data and a short performance analysis of the top [query_count] queries typically close it out.
Pro tips
- Make
[requirements]as concrete as possible; listing the real entities and actions ("track time, generate invoices, manage teams") produces a far more accurate schema than abstract goals. - Be honest about
[normal_form]; asking for "3NF with strategic denormalization" gives you cleaner trade-off reasoning than demanding strict normalization everywhere. - Name your actual
[query_patterns]so the index recommendations are useful rather than generic. - Identify the real
[large_table]up front, because partitioning advice is only meaningful when it targets the table that will actually grow. - If you use a specific ORM, set
[migration_tool]to match it (Laravel migrations, Alembic, Prisma) so the output drops straight into your project. - Iterate by pasting the generated schema back and asking it to add a new entity or stress-test a particular query path.
