3 ms·
What’s so much more compelling about a graph db than a “with recursive” sql call? And even such recursive sql calls should be fairly rare since you would rather
by aabhay 1y ago
What’s so much more compelling about a graph db than a “with recursive” sql call? And even such recursive sql calls should be fairly rare since you would rather cache frequently accessed foreign key relationships anyway.
- jlokier 1y agoAmong other things, some graph DBs are designed to perform the equivalent of "with recursive", filtering by attributes as you chase links and/or calculating statistics over subgraphs, more efficiently than SQL databases. If you're just pulling up a tree of comments on an article using parent-child relations, SQL will be fine, though for query latency you might be better off with a "flat list" article-comment relation instead and recovering the tree structure after fetching the comments.
- hobofan 1y agoI've yet to see any of the typical commercially available graph databases do anything fancy in that regard. If you dive into the query plans of a graph DB you quickly see that there is nothing special about that. In the end it boils down to the same physical joins on node and vertex tables. The only thing graph DBs offer over your typical RDBMS is nicer syntax (while having worse operational maturity), and with the advent of SQL/PGQ event that advandtage is going away.
- dboreham 1y agoUnder the hood they're basically the same (modulo graph databases are generally less mature and less featureful in their storage implementation). The main difference is impedance match with the human writing the query. Graph databases offer query language semantics that are easier to write and reason about, for graphy workloads.