Problem
Poor data models cause: query complexity, write contention, schema migration pain, reporting inconsistency. Need systematic modeling patterns.
data-stateestablished · medium operational burden
Data Modeling Patterns
Also known as: data-modeling, schema-design, database-design, normalization, denormalization
Intent
Design scalable, maintainable data models: normalization, denormalization, entity relationships, temporal data, polymorphic associations.
Forces
- •Normalization: reduce redundancy, enforce integrity (1NF-3NF, BCNF)
- •Denormalization: query performance, read optimization
- •Evolution: schema changes without downtime (expand/contract)
- •Consistency: ACID vs eventual, referential integrity
Solution
✓ When to Use
- •Any system with relational data
- •Schema evolution without downtime
- •Query performance optimization
- •Multi-tenant data isolation
✗ When Not to Use
- •Document/NoSQL primary (different patterns)
- •Team not ready for modeling discipline
Pros
- +Scalable, maintainable data layer
- +Zero-downtime migrations
- +Query performance by design
- +Data integrity by constraints
Cons
- −Upfront design investment
- −Migration complexity (expand/contract)
- −Denormalization sync complexity
- −Polymorphic anti-pattern temptation
Cost Profile
Infrastructure
Low — design discipline, migration tools
Operational
Medium — migration process, index maintenance
Cognitive
High — normalization, denormalization, temporal
Failure Modes
Over-normalized: 10 joins for simple query
Over-denormalized: stale data, write storms
Missing indexes: sequential scans on large tables
Migration failure: partial state, manual recovery
Polymorphic queries: no index, no FK, slow
Real-World Examples
Alternatives
- nosql
- document-store
- graph-db
- columnar-store
Related Patterns
- database-indexing
- database-migration
- partitioning-strategies
- multi-tenancy-patterns
- temporal-data
- audit-log
- cdc
Competency Domains
data statereliability opseconomics evolutionscalingdeploymentsecurity compliance