4 ms·

> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer All graph databases? With just a bit of googling I c

> graph databases push foreign keys, joins, referential integrity, and migrations to the application layer All graph databases? With just a bit of googling I can find ones that support migrations through ETL with foreign keys translated to edges at that point, and claim to have transactions with immediate consistency—even some claiming ACID. Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept.

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 ago
  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 In an graphdb the engine would deduct that by the way of the query language (no explicit joins).
  - j-pb 5y ago
    Yes, 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 ago
  O(1) traversal, and filtering edges is more intuitive than joining.
  - j-pb 5y ago
    And 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 ago
      Depends on what’s under the hood, though. A lot of these seem to be document or columnar stores.
      - j-pb 5y ago
        Well, 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 ago
        But 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 ago
        You 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 ;)
jandrewrogers 5y ago
> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Joins are the central thing in graph databases, even if you don't think of it in those terms or materialize some of the join operations. Being able to directly query across edges is a logical operation, it doesn't imply the underlying implementation. While the simple "node/edge" model in memory seems easy, it also has pathologically poor locality so most graph databases use less direct representations (traversed with join operations under the hood) with much higher average performance.
- eurasiantiger 5y ago
  You could make the same argument for any columnar store. Getting fields from one is fast, though, independent of the table they belong to. Joining together row-based tables has more moving parts and much more runtime cost.

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 ago
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 In an graphdb the engine would deduct that by the way of the query language (no explicit joins).
- j-pb 5y ago
  Yes, 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 ago
O(1) traversal, and filtering edges is more intuitive than joining.
- j-pb 5y ago
  And 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 ago
    Depends on what’s under the hood, though. A lot of these seem to be document or columnar stores.
    - j-pb 5y ago
      Well, 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 ago
        But 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 ago
        You 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 ;)

jandrewrogers 5y ago

> Joins are not even a thing in graph databases; being able to directly query across edges obviates the entire concept. Joins are the central thing in graph databases, even if you don't think of it in those terms or materialize some of the join operations. Being able to directly query across edges is a logical operation, it doesn't imply the underlying implementation. While the simple "node/edge" model in memory seems easy, it also has pathologically poor locality so most graph databases use less direct representations (traversed with join operations under the hood) with much higher average performance.

eurasiantiger 5y ago
You could make the same argument for any columnar store. Getting fields from one is fast, though, independent of the table they belong to. Joining together row-based tables has more moving parts and much more runtime cost.