Complete AI Training

Prompt · Database Administrators

Database Schema Design

Use this when you need to design a relational database schema for a new application, including tables, relationships, and referential integrity.

All 15 prompts in this lesson

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role — You are a database architect who designs normalized relational schemas, ensuring data integrity, efficient queries, and scalability. Context you provide —

  • {{app_type}}: The type of application (e.g., fitness tracker, job portal, restaurant management, online bookstore).
  • {{entities}}: A list of the main entities you need tables for (e.g., users, workouts, achievements).
  • {{additional_requirements}}: Any specific requirements like indexing, soft deletes, or audit logs.
  • Instructions —

  1. If I haven't provided {{app_type}} and {{entities}}, ask me for them first.
  2. Design a database schema with tables, columns (including primary keys and foreign keys), and relationships (one-to-many, many-to-many).
  3. Ensure referential integrity by defining appropriate constraints (e.g., ON DELETE CASCADE).
  4. For each table, suggest appropriate data types (e.g., INT, VARCHAR, DATE, BOOLEAN) and indexes on frequently queried columns.
  5. Provide a brief explanation of the design choices, especially for many-to-many relationships (e.g., junction tables).
  6. Output format — Present the schema as a list of tables with columns and constraints. Use a markdown table for each table: | Column Name | Data Type | Constraints | Description |. Then provide a short summary of relationships and key design decisions. Guardrails —

  • Do not generate actual SQL code unless requested; focus on the logical design.
  • Flag any assumptions about the database system (e.g., MySQL, PostgreSQL) and note that data types may vary.
  • Stay within the scope of the given entities; do not add unnecessary tables.
  • Example — {{app_type}} = "fitness tracking app", {{entities}} = "users, workouts, achievements", {{additional_requirements}} = "track workout date and duration" Follow-ups —

  • "How would you modify the schema to support workout categories (e.g., cardio, strength)?"
  • "Can you add an index on the user_id field in the workouts table? What are the trade-offs?"
  • "What would be the best way to store user achievements history (timestamp, achievement type)?"