Database Design
Overview
Provides comprehensive guidance for designing robust, scalable, and maintainable database schemas for both relational (SQL) and NoSQL databases, from conceptual modeling to physical implementation.
Design Workflow
- Requirements Analysis - Gather data requirements and usage patterns
- Conceptual Modeling - Create entity-relationship diagrams (ERD)
- Logical Modeling - Define normalized schema with relationships
- Physical Modeling - Select data types, indexes, and constraints
- Validation - Review design against requirements and best practices
Quick Start
Basic E-commerce Schema:
-- Users table
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Products table
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
description TEXT,
price DECIMAL(10,2) NOT NULL,
stock_quantity INTEGER DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_name (name)
);
-- Orders table
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
user_id INTEGER REFERENCES users(id),
total_amount DECIMAL(10,2) NOT NULL,
status VARCHAR(50) DEFAULT 'pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user_created (user_id, created_at)
);
Core Principles
- Start normalized, denormalize only when proven necessary
- Index strategically based on actual query patterns
- Use constraints to enforce data integrity at database level
- Choose appropriate data types to optimize storage and performance
- Plan for growth with partitioning and sharding strategies
- Document design decisions and their rationale
- Test with realistic data volumes
When to Load References
Design Workflow: See database-design-workflow.md for step-by-step design process including requirements analysis, conceptual/logical/physical modeling, normalization steps, and relationship patterns
Advanced Patterns: See advanced-design-patterns.md for many-to-many relationships, inheritance/polymorphism, temporal data, soft deletes, audit trails, and hierarchical data
NoSQL Design: See nosql-database-design.md when designing MongoDB documents, Cassandra column families, or Redis data structures
Anti-Patterns: See common-anti-patterns-to-avoid.md to identify EAV pattern issues, generic tables, redundant data, multi-value columns, and other problematic designs
Performance: See performance-optimization.md for query optimization, partitioning strategies, caching patterns, and index tuning
Migration: See schema-migration-best-practices.md for zero-downtime migrations, backward compatibility, and rollback strategies
Checklist: See database-design-checklist.md for comprehensive validation before implementation
1---2name: database-design-53description: Designs comprehensive database schemas including relational and NoSQL models, normalization, indexing strategies, relationship modeling, data types, constraints, and performance optimization. Covers entity-relationship diagrams, schema migrations, partitioning, and best practices for PostgreSQL, MySQL, MongoDB, and other databases. Use when designing databases, creating schemas, modeling data, optimizing queries, or when users mention "database design", "schema design", "data modeling", "ERD", "normalization", "indexing", or "database architecture".4---5
6# Database Design
7
8## Overview
9
10Provides comprehensive guidance for designing robust, scalable, and maintainable database schemas for both relational (SQL) and NoSQL databases, from conceptual modeling to physical implementation.
11
12## Design Workflow
13
141. **Requirements Analysis** - Gather data requirements and usage patterns
152. **Conceptual Modeling** - Create entity-relationship diagrams (ERD)
163. **Logical Modeling** - Define normalized schema with relationships
174. **Physical Modeling** - Select data types, indexes, and constraints
185. **Validation** - Review design against requirements and best practices
19
20## Quick Start
21
22**Basic E-commerce Schema:**
23
24```sql
25-- Users table
26CREATE TABLE users (
27 id SERIAL PRIMARY KEY,
28 email VARCHAR(255) UNIQUE NOT NULL,
29 password_hash VARCHAR(255) NOT NULL,
30 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
31);
32
33-- Products table
34CREATE TABLE products (
35 id SERIAL PRIMARY KEY,
36 name VARCHAR(255) NOT NULL,
37 description TEXT,
38 price DECIMAL(10,2) NOT NULL,
39 stock_quantity INTEGER DEFAULT 0,
40 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
41 INDEX idx_name (name)
42);
43
44-- Orders table
45CREATE TABLE orders (
46 id SERIAL PRIMARY KEY,
47 user_id INTEGER REFERENCES users(id),
48 total_amount DECIMAL(10,2) NOT NULL,
49 status VARCHAR(50) DEFAULT 'pending',
50 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
51 INDEX idx_user_created (user_id, created_at)
52);
53```
54
55## Core Principles
56
57- **Start normalized, denormalize only when proven necessary**
58- **Index strategically based on actual query patterns**
59- **Use constraints to enforce data integrity at database level**
60- **Choose appropriate data types to optimize storage and performance**
61- **Plan for growth with partitioning and sharding strategies**
62- **Document design decisions and their rationale**
63- **Test with realistic data volumes**
64
65## When to Load References
66
67- **Design Workflow**: See [database-design-workflow.md](references/database-design-workflow.md) for step-by-step design process including requirements analysis, conceptual/logical/physical modeling, normalization steps, and relationship patterns
68
69- **Advanced Patterns**: See [advanced-design-patterns.md](references/advanced-design-patterns.md) for many-to-many relationships, inheritance/polymorphism, temporal data, soft deletes, audit trails, and hierarchical data
70
71- **NoSQL Design**: See [nosql-database-design.md](references/nosql-database-design.md) when designing MongoDB documents, Cassandra column families, or Redis data structures
72
73- **Anti-Patterns**: See [common-anti-patterns-to-avoid.md](references/common-anti-patterns-to-avoid.md) to identify EAV pattern issues, generic tables, redundant data, multi-value columns, and other problematic designs
74
75- **Performance**: See [performance-optimization.md](references/performance-optimization.md) for query optimization, partitioning strategies, caching patterns, and index tuning
76
77- **Migration**: See [schema-migration-best-practices.md](references/schema-migration-best-practices.md) for zero-downtime migrations, backward compatibility, and rollback strategies
78
79- **Checklist**: See [database-design-checklist.md](references/database-design-checklist.md) for comprehensive validation before implementation