Data Modeling for Software Engineers
summary
Teams implement data ad hoc but modeling still matters for API payloads and messages, config files, caches and databases. Concrete pitfalls: five different address tables and mismatched zip fields that lose specificity, a device ingest pattern that wastes an estimated $75–$100k/month by writing unchanged telemetry, and a FHIR implementation whose relational schema breaks reporting. Practical rules: require a use case before capturing fields, use standards (ISO 3166, 8601), don't expose primary keys, and store timestamps as UTC.
AI-written summary · about
chapters (13)
- 0:00Data modeling intro
- 4:41From formal to informal architecture
- 7:29Why data outlasts code
- 9:35Design choices shape future
- 13:30Where data appears in systems
- 19:56Data modeling beyond waterfall
- 22:24Why data is harder to reverse
- 26:37Cost of ignoring standards
- 31:59Common modeling pitfalls
- 38:00Hiding implementation details
- 44:41Internal vs external contracts
- 48:13Benefits of disciplined modeling
- 51:44Final advice
related talks
01h 02mDesign Good Schemas - Get a Better Database
18mDemystifying Data Modeling
43mScaling Data Stacks: How To Build a Great Data Model
55mData Modeling in a Non-Relational World
52mScaling Data Teams: Three Pitfalls and How To Avoid Them
45mData Modeling in an Event Centric World
48mJSON Data Modeling
34mDimensional Data Modeling in the Modern Era