Your data model is terrible! Let me show you why.
summary
Drupal data models create real costs and tradeoffs: using depcalc to map dependencies shows a node can pull 37 related entities into a manifest and generate 2,800+ lines of JSON, while a different model halves that. A commerce case compresses 700,000 variants → 700 by moving nonprice fields to line items. Paragraphs plus entity_reference_revisions produce massive bloat—clients report 50GB tables—and nested paragraph edits create needless revisions; layout builder or custom field plugins avoid much of this.
AI-written summary · about
chapters (23)
- 0:00Intro
- 1:17What is data modelling
- 1:50Entity references
- 4:26Drupal Commerce story
- 7:24How we fixed it
- 8:27Drupal 8 horror story
- 10:20Is there a happy ending
- 11:03Fields that reference things
- 17:00Paragraphs
- 18:05Bundles
- 18:40Revisions
- 19:56Demo
- 26:38Layout Builder
- 29:28Data Modeling Best Practices
- 31:15When and Where to Reference
- 32:16OnetoOne Reference
- 37:12New Entity Types
- 38:33Why do I know this
- 40:18Another window
- 40:30Project management tool
- 42:59Content Hub
- 43:18Data Model
- 49:27Questions
related talks
55mData Modeling for Software Engineers
52m"Decoupled Drupal: Implications, risks and changes from a business perspective"
26mNoSQL Data Modeling for Front-end Developers
22mUnderstanding Dependencies in JavaScript to Create More Performant App
29mA New Paradigm: How Do I Optimally Break my UI Into Queries?
45mSet your data free with model-based architecture diagramming
45mLearning to Love DDD - a Tale of Two Products
29mExtreme Page composition