Overview
Designs well-normalized relational database schemas (target 3NF with pragmatic denormalization where justified). Covers naming conventions, primary key strategies (UUID vs serial/bigserial), foreign keys with cascade options, index design, soft delete pattern, audit columns, and generation of ER diagrams from SQL.
When to Use This Skill
- Designing the data model for a new application or feature.
- Refactoring a messy or performance-problematic schema.
- The user provides business requirements or an existing schema to improve.
Prerequisites
- Understanding of the domain and entities/relationships.
- Chosen database (PostgreSQL strongly recommended for new projects; MySQL/SQLite also supported).
- Tool for ERD generation (dbdiagram.io, draw.io, or
schemaspy / pgadmin).
Steps
Identify entities and relationships:
- List all nouns that need to be stored.
- Define relationships (one-to-many, many-to-many, one-to-one).
Normalization:
- 1NF: atomic values, no repeating groups.
- 2NF: no partial dependency on composite PK.
- 3NF: no transitive dependencies.
- Note when to denormalize (read-heavy reporting tables, materialized views).
Naming & conventions:
- Tables: plural snake_case (
users, order_items).
- Columns: snake_case, consistent (
created_at, updated_at).
- Primary keys:
id (bigserial or uuid).
- Foreign keys:
user_id, order_id.
Keys & constraints:
- Primary key.
- Foreign keys with
ON DELETE / ON UPDATE (RESTRICT, CASCADE, SET NULL — choose deliberately).
- Unique constraints.
- Check constraints for business rules (e.g.,
price > 0).
- Not null where appropriate.
Indexes:
- B-tree on foreign keys (almost always).
- Composite on common filter + sort combinations.
- Partial indexes for common subsets.
- GIN for JSONB, full-text, arrays when needed.
Patterns:
- Soft delete (
deleted_at + is_deleted generated column or partial unique indexes).
- Audit columns (
created_at, updated_at, created_by, updated_by).
- JSONB for flexible attributes (with GIN index).
Output:
- Complete
CREATE TABLE statements (Postgres syntax, adaptable).
- Index creation statements.
- ERD (Mermaid or dbdiagram.io syntax).
- Migration notes (how to apply without downtime).
Examples
A complete e-commerce schema (users, products, orders, order_items, reviews, inventory) with proper normalization, indexes, soft deletes, audit columns, and a Mermaid ERD is included, plus a denormalized reporting table example with justification.
Edge Cases & Error Handling
- Polymorphic associations: Use a join table or separate tables per type instead of a single foreign key + type column when possible.
- High cardinality: Careful with indexes on very high-cardinality columns.
- Sharding / partitioning: Note when a table will need to be partitioned by date or tenant.
Verification
- All
CREATE TABLE statements run cleanly on a fresh database.
- Foreign key constraints prevent invalid data.
- Common queries have efficient plans (EXPLAIN shows index usage).
- ERD matches the SQL.
- Soft delete and audit columns are present where expected.
- Success: Schema is normalized, constraints protect data integrity, and common access patterns are fast.
References
1---2name: database-schema-designer3description: Designs normalized relational database schemas with proper constraints, indexes, and relationships. Use when modeling data for a new application or refactoring an existing schema.4license: Apache-2.05---67## Overview89Designs well-normalized relational database schemas (target 3NF with pragmatic denormalization where justified). Covers naming conventions, primary key strategies (UUID vs serial/bigserial), foreign keys with cascade options, index design, soft delete pattern, audit columns, and generation of ER diagrams from SQL.1011## When to Use This Skill1213- Designing the data model for a new application or feature.14- Refactoring a messy or performance-problematic schema.15- The user provides business requirements or an existing schema to improve.1617## Prerequisites1819- Understanding of the domain and entities/relationships.20- Chosen database (PostgreSQL strongly recommended for new projects; MySQL/SQLite also supported).21- Tool for ERD generation (dbdiagram.io, draw.io, or `schemaspy` / `pgadmin`).2223## Steps24251. **Identify entities and relationships**:26 - List all nouns that need to be stored.27 - Define relationships (one-to-many, many-to-many, one-to-one).28292. **Normalization**:30 - 1NF: atomic values, no repeating groups.31 - 2NF: no partial dependency on composite PK.32 - 3NF: no transitive dependencies.33 - Note when to denormalize (read-heavy reporting tables, materialized views).34353. **Naming & conventions**:36 - Tables: plural snake_case (`users`, `order_items`).37 - Columns: snake_case, consistent (`created_at`, `updated_at`).38 - Primary keys: `id` (bigserial or uuid).39 - Foreign keys: `user_id`, `order_id`.40414. **Keys & constraints**:42 - Primary key.43 - Foreign keys with `ON DELETE` / `ON UPDATE` (RESTRICT, CASCADE, SET NULL — choose deliberately).44 - Unique constraints.45 - Check constraints for business rules (e.g., `price > 0`).46 - Not null where appropriate.47485. **Indexes**:49 - B-tree on foreign keys (almost always).50 - Composite on common filter + sort combinations.51 - Partial indexes for common subsets.52 - GIN for JSONB, full-text, arrays when needed.53546. **Patterns**:55 - Soft delete (`deleted_at` + `is_deleted` generated column or partial unique indexes).56 - Audit columns (`created_at`, `updated_at`, `created_by`, `updated_by`).57 - JSONB for flexible attributes (with GIN index).58597. **Output**:60 - Complete `CREATE TABLE` statements (Postgres syntax, adaptable).61 - Index creation statements.62 - ERD (Mermaid or dbdiagram.io syntax).63 - Migration notes (how to apply without downtime).6465## Examples6667A complete e-commerce schema (users, products, orders, order_items, reviews, inventory) with proper normalization, indexes, soft deletes, audit columns, and a Mermaid ERD is included, plus a denormalized reporting table example with justification.6869## Edge Cases & Error Handling7071- **Polymorphic associations**: Use a join table or separate tables per type instead of a single foreign key + type column when possible.72- **High cardinality**: Careful with indexes on very high-cardinality columns.73- **Sharding / partitioning**: Note when a table will need to be partitioned by date or tenant.7475## Verification76771. All `CREATE TABLE` statements run cleanly on a fresh database.782. Foreign key constraints prevent invalid data.793. Common queries have efficient plans (EXPLAIN shows index usage).804. ERD matches the SQL.815. Soft delete and audit columns are present where expected.826. Success: Schema is normalized, constraints protect data integrity, and common access patterns are fast.8384## References8586- [PostgreSQL Data Types](https://www.postgresql.org/docs/current/datatype.html)87- [Database Normalization](https://en.wikipedia.org/wiki/Database_normalization)88- [Use The Index, Luke - Indexing](https://use-the-index-luke.com/sql/where-clause)89- [dbdiagram.io](https://dbdiagram.io/)90- [PostgreSQL Constraints](https://www.postgresql.org/docs/current/ddl-constraints.html)