> For example, to store a graph in a RDBMS, the ideal format is probably an adjacency list with a recursive query to iterate it I know this was a minor point,

> For example, to store a graph in a RDBMS, the ideal format is probably an adjacency list with a recursive query to iterate it I know this was a minor point, but I think it speaks to the overall topic, so I'll poke at it. Adjacency lists are perhaps the worst way to store a graph / tree in RDBMS. They may be the easiest to understand, but they have some of the worst performance characteristics, especially if your RDBMS doesn't have Recursive CTEs. This starts to matter at a much lower scale than you might think; several million rows is enough to start showing slowdowns. This book [0] (Joe Celko's Trees and Hierarchies in SQL For Smarties) shows many other options, though it does lack the closure table approach [1], which is my preferred approach. And here, we come full circle back to the long-held friction between DBs and applications. You start mentioning triggers, and devs flinch, stating that they don't want logic in the DB. In every case I've ever seen, the replacements they come up with is incredibly convoluted and prone to errors, but hey, it's not in the DB. There is no reason to fear triggers, if and only if you treat them the same way that you'd treat code (because it is): added/modified/removed only via PRs, with careful review and testing. [0]: https://ia804505.us.archive.org/19/items/0411-pdf-celko-trees-and-hierarchies-in-sql-for-smarties-elsevier-2004/0411%20pdf%20Celko%20-%20Trees%20and%20Hierarchies%20in%20SQL%20for%20Smarties%20%28Elsevier%2C%202004%29.pdf https://ia804505.us.archive.org/19/items/0411-pdf-celko-tree... [1]: https://dirtsimple.org/2010/11/simplest-way-to-do-tree-based-queries.html https://dirtsimple.org/2010/11/simplest-way-to-do-tree-based...