4 ms·
> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Nah, you do need joins if you don't onl
by j-pb 5y ago
> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept.
Nah, you do need joins if you don't only want to walk the graph from some well known roots.
E.g. queries about properties of connected subgraphs
- Scarbutt 5y agoNah, you do need joins if you don't only want to walk the graph from some well known roots. E.g. queries about properties of connected subgraphs In an graphdb the engine would deduct that by the way of the query language (no explicit joins).
- j-pb 5y agoYes, and then do a join ;) I'm not arguing for explicit joins, which are an artifact of SQL and not even the relational model e.g. Datalog as a explicit join free relational language.
- eurasiantiger 5y agoO(1) traversal, and filtering edges is more intuitive than joining.
- j-pb 5y agoAnd also not O(1) nor intuitive for any non trivial query. You don't need to have an explicit `JOIN` operator in your language, but any query that goes beyond unconditional tree walking will benefit from using joins under the hood.
- eurasiantiger 5y agoDepends on what’s under the hood, though. A lot of these seem to be document or columnar stores.
- j-pb 5y agoWell, still. Columnar and document stores still profit from performing joins under their hood. Whenever you are combining two partial query results into a coherent whole answer you need to perform some form of join. For example you could view a MongoDB map-reduce step with a subquery as a naive indexless scan join.
- eurasiantiger 5y agoBut there is no other query, except if you count each and every traversal originating from each record. The top-level query can traverse edges to reach other vertices, so first it gets a result set, then for each result, fields across relations, etc. In traditional join sense, a RDBMS first gets two or more result sets, then filters and matches one, both or neither to appropriate rows in the other one. It is a different concept entirely. Suffice to say, one of these is conceptually easier to parallelize and distribute.
- j-pb 5y agoYou seem to be stuck on the query semantic level. I can highly recomend actually building a graph database, and using it in anger in a project. You'll realize that all these paradigms are more related than they appear on the surface, that the obvious and naive thing is also often prohibitively slow and limited, and that NoSQL doesn't mean NoJOIN ;)
- eurasiantiger 5y agoI don’t care about implementation details. I care about performance and team velocity; the former is already implemented and the latter comes from being able to just define a graph data model and get a free GraphQL API for frontend developers in return.
- j-pb 5y ago> the former is already implemented Yeah, with joins, which this entire discussion is about. > the latter Is completely tangential.