designing-database-schemas

Database Schema Designer

Overview

Design normalized relational database schemas from business requirements, entity-relationship diagrams, or existing application code. This skill produces PostgreSQL or MySQL DDL with proper data types, constraints, indexes, and relationships following normalization principles (3NF by default) with strategic denormalization where performance requires it.

Prerequisites

• Business domain requirements or existing application models/classes to derive schema from
• psql or mysql CLI for testing schema DDL
• Target database engine and version (determines available data types and features)
• Expected data volumes and query patterns for sizing and index decisions
• Multi-tenancy requirements (shared schema, schema-per-tenant, or database-per-tenant)

Instructions

1. Identify all entities (nouns) from the business requirements. Each entity becomes a table. List every attribute (property) of each entity and classify as required or optional.

2. Define primary keys for each table. Prefer BIGSERIAL (PostgreSQL) or BIGINT AUTO_INCREMENT (MySQL) for surrogate keys. Use UUID (via gen_random_uuid()) for distributed systems or when IDs are exposed in URLs. Natural keys are acceptable when truly immutable and unique (ISO country codes, IATA airport codes).

3. Normalize the schema to Third Normal Form (3NF):

   • 1NF: Eliminate repeating groups. Each column holds a single atomic value. No arrays in columns (unless using PostgreSQL array types intentionally).
   • 2NF: Remove partial dependencies. Every non-key column depends on the entire primary key.
   • 3NF: Remove transitive dependencies. Non-key columns depend only on the primary key, not on other non-key columns. Extract lookup tables for values that change independently.

4. Define relationships between tables:

   • One-to-many: Add a foreign key column on the "many" side referencing the "one" side. Example: orders.customer_id REFERENCES customers(id).
   • Many-to-many: Create a junction table with two foreign keys. Example: product_categories(product_id, category_id) with a composite primary key.
   • One-to-one: Add a foreign key with a UNIQUE constraint, or merge into a single table if entities are always accessed together.

5. Choose appropriate data types with precision:

   • Money: NUMERIC(12,2) or INTEGER storing cents (never FLOAT/DOUBLE)
   • Timestamps: TIMESTAMPTZ (PostgreSQL) with time zone for events; DATE for calendar dates
   • Status fields: VARCHAR(20) with CHECK constraint, or create an ENUM type
   • Email: CITEXT (PostgreSQL) or VARCHAR(254) with CHECK constraint for format validation
   • JSON: JSONB (PostgreSQL) for flexible schema attributes; avoid for core relational data

6. Add standard columns to every table:

   • created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
   • updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() (with trigger for auto-update)
   • deleted_at TIMESTAMPTZ for soft delete (add partial index WHERE deleted_at IS NULL)

7. Define constraints: NOT NULL on required fields, UNIQUE on natural keys and email addresses, CHECK constraints for value validation (CHECK (price >= 0), CHECK (status IN ('active', 'inactive'))), and foreign keys with appropriate ON DELETE behavior (CASCADE, SET NULL, or RESTRICT).

8. Design indexes based on expected query patterns:

   • Primary key index is automatic
   • Foreign key columns: always index these for JOIN performance
   • Columns in WHERE clauses with high selectivity: B-tree index
   • Full-text search columns: GIN index on tsvector
   • Composite indexes: match the most common multi-column filter patterns, leftmost column first

9. Apply strategic denormalization where 3NF causes unacceptable query complexity:

   • Materialized views for expensive aggregate queries
   • Denormalized counter columns (with trigger-based updates) for counts displayed on every page load
   • JSON columns for flexible metadata that varies by record type

10. Generate the complete DDL script with CREATE TABLE statements in dependency order (referenced tables first), followed by indexes, triggers, and any seed data for lookup tables.

Output

• Complete DDL script with CREATE TABLE, constraints, indexes, and triggers in executable order
• Entity-relationship description listing all tables, columns, types, and relationships
• Index strategy document explaining which indexes support which query patterns
• Seed data scripts for lookup/reference tables (countries, statuses, categories)
• Migration file compatible with the project's migration framework

Error Handling

Error	Cause	Solution
Circular foreign key dependency	Tables reference each other, preventing creation in any order	Use ALTER TABLE ADD CONSTRAINT after both tables are created; or redesign to eliminate the cycle with a junction table
Over-normalization causing excessive JOINs	Every lookup value in its own table, queries require 8+ JOINs	Denormalize low-cardinality, rarely-changing lookup values; use ENUM types for status fields instead of separate tables
NUMERIC precision overflow	Monetary values exceed NUMERIC(10,2) maximum	Increase precision to NUMERIC(15,2) or NUMERIC(19,4) for currencies requiring sub-cent precision
Schema too rigid for evolving requirements	Frequent ALTER TABLE needed as business rules change	Use JSONB columns for flexible attributes; implement the EAV (Entity-Attribute-Value) pattern for truly dynamic schemas; plan for schema evolution from the start
Missing index on foreign key column	JOINs on foreign key columns cause sequential scans	Always create indexes on foreign key columns; PostgreSQL does not auto-index foreign keys (unlike MySQL InnoDB)

Examples

E-commerce schema design: Tables: customers, addresses (one-to-many from customers), products, categories (many-to-many via product_categories), orders, order_items (one-to-many from orders), payments. Money stored as NUMERIC(12,2). Soft delete on customers and products. GIN index on products.search_vector for full-text search. Composite index (customer_id, created_at DESC) on orders for order history pages.

Multi-tenant SaaS schema with row-level security: Every table includes tenant_id BIGINT NOT NULL with a foreign key to tenants. Row-level security policies enforce tenant isolation: CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::bigint). Composite indexes start with tenant_id for partition-like query performance.

Event sourcing schema: An events table with (aggregate_id, sequence_number) as composite primary key, event_type VARCHAR(100), payload JSONB, created_at TIMESTAMPTZ. A snapshots table stores materialized state at periodic intervals. Append-only design with no UPDATE or DELETE operations.

Resources

• PostgreSQL data types: https://www.postgresql.org/docs/current/datatype.html
• Database normalization: https://en.wikipedia.org/wiki/Database_normalization
• PostgreSQL row-level security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• Index design guide: https://use-the-index-luke.com/
• Schema design patterns: https://www.postgresql.org/docs/current/ddl.html