Design Good Schemas - Get a Better Database
summary
Schemas prioritize atomic columns and domain-correct types over blobs or JSON, because opaque data types (full name, blob, packed JSON) break sorting, querying and future changes; multi-entity rows and EAV patterns create sparse nulls, lock hotspots and painful joins; primary keys prefer stable, meaningful values rather than sequential exposed IDs to avoid join bloat and environment drift; schema changes have graded costs (create cheap, altering FK columns or types costly); use migration scripts (Flyway/Liquibase) and treat ORMs as helpers for connection/codec not schema design.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 0:45Design good schemas
- 1:37Fitness criteria
- 4:10Model vs Schema
- 4:50Design vs Schema
- 5:28Model
- 6:31Schema
- 11:25Regrets
- 12:35Impact of change
- 16:25Data types
- 21:55How to fix data types
- 22:34Denormalization
- 25:13Multientity table
- 26:05Catalog item example
- 27:48How to fix this
- 30:11Abnormal Form
- 36:28References
- 45:36Sequential Keys
- 48:09Primary Keys
- 50:58ORM
- 55:57RMS
- 57:47Adhoc DDL
- 58:42Migration scripts
- 59:33Summary
