Rails anti-patterns: how not to design your database
summary
Warns that at Procore a 14‑terabyte database handles heavy load (about 50,000 reads/writes) so design choices matter. Shows closure_tree gem (ancestor/descendent table) and ancestry gem (materialized path) with tradeoffs: single-join fast reads, reparenting cost, no referential integrity for paths, and benchmark-dependent performance. Compares polymorphic relations versus exclusive foreign keys and a base‑parent table, noting when polymorphic relationships scale for many parent types and when foreign keys or extracted parent rows give safer, faster integrity.
AI-written summary · about
chapters (14)
- 0:00Start
- 8:18Naive Trees
- 11:47Deleting in a Tree
- 13:05The Closure Tree
- 15:02Closure Tree
- 15:41Referential Integrity
- 15:59Materialized Path
- 17:26Ancestry
- 18:04Performance Comparison
- 19:18Anti-Pattern Number Two Polymorphic Relationships
- 21:48Disadvantages
- 23:23Exclusive Arcs
- 24:44Base Parent Table
- 26:34Recap
related talks
32mRails Sustainable Productivity
33mExperimental Patterns in ActiveRecord
26mBiggish Data With Rails and Postgresql
01h 52mBuild High Performance Active Record Apps
01h 52mBuild High Performance Active Record Apps
50mConvenience vs Simplicity
14mDatabase Performance at Scale for RoR Applications
41mAn Intervention for ActiveRecord