4 ms·

It's faster, but it's not remarkably faster, no. The main place it becomes faster is deep joins - if you want the friend of the friend of the friend. If using j

by RyanZAG 13y ago

It's faster, but it's not remarkably faster, no. The main place it becomes faster is deep joins - if you want the friend of the friend of the friend. If using joins that looks like LEFT OUTER JOIN bla a1 LEFT OUTER JOIN bla a2 LEFT OUTER JOIN bla a3 etc. If you've got much experience with SQL you should realize the performance impact of that. So graph dbs are best suited to highly networked problems. Denormalize is something different, you're misunderstanding something I've said. With a graph DB, you still only have 1 copy of each person - you are just storing the 'joins' or ids/addresses of the 'rows' you want to join with ahead of time. I certainly did not say that joins are bad, I was just answering your questions as to how a graph db differs and why it would perform better in certain specific circumstances. If you're in those circumstances then a graph DB is very useful. Another nice part of a graph db is if you have a large collection of different objects in your programming language that all interact with each other. Those interactions can be stored directly in-line and allow for an ORM layer to be more efficient when retrieving the whole collection.

dragonwriter 13y ago
> The main place it becomes faster is deep joins - if you want the friend of the friend of the friend. If using joins that looks like LEFT OUTER JOIN bla a1 LEFT OUTER JOIN bla a2 LEFT OUTER JOIN bla a3 etc. If you want all friends out to some specified distance n where n > 1, recursive CTEs are a much more sane solution that anything involving n levels of OUTER JOINs. And if you just want specifically friends-of-friends-of-friends by joins, you want three levels of INNER JOINS. > With a graph DB, you still only have 1 copy of each person - you are just storing the 'joins' or ids/addresses of the 'rows' you want to join with ahead of time. More accurately, graph DBs store addresses (not ids/addresses) while RDBMS store ids (Foreign Keys) of the records you want to join with ahead of time. This means that to get from one record to a related record takes an additional level of indirection in an RDBMS compared to a graph database, but that doing so from many similar structured records to their equivalent linked records is more efficient in an RDBMS. > Another nice part of a graph db is if you have a large collection of different objects in your programming language that all interact with each other. Those interactions can be stored directly in-line and allow for an ORM layer to be more efficient when retrieving the whole collection. With a Graph DB instead of an RDBMS, you obviously wouldn't haven a ORM (Object-Relational Mapping) layer in any case. At more than one level out
- RyanZAG 13y ago
  Recursive CTEs are not what one would traditionally call 'relational' and many relational databases certainly don't have them. Some distributed graph databases do store ids and not addresses - there is no actual requirement that they be addresses, only that they be efficient to retrieve. So not actually more accurate. People still call object-db mappers 'ORMs' even when dealing with document databases such as Google's bigtable or MongoDB. It's just an acronym at this point. [1][2] [1] - http://mongomapper.com/ http://mongomapper.com/ [2] - https://code.google.com/p/mongo-java-orm/ https://code.google.com/p/mongo-java-orm/ EDIT: By 'id' I'm referring to some unique hash or key that can be used to locate a document. By 'address' I'm referring to an actual on-disk location that can be directly loaded. Maybe my definitions clash with yours, I don't think this stuff is formally defined.
  - dragonwriter 13y ago
    > Recursive CTEs are not what one would traditionally call 'relational' I'm not a big fan of tradition for its own sake. > and many relational databases certainly don't have them. The only major SQL-based RDBMSs I can think of off the top my head that don't support recursive CTEs in their current version are SQLite and MySQL -- Postgres, Firebird, DB2, Oracle, and MS SQL Server all do.

by RyanZAG 13y ago

dragonwriter 13y ago

> The main place it becomes faster is deep joins - if you want the friend of the friend of the friend. If using joins that looks like LEFT OUTER JOIN bla a1 LEFT OUTER JOIN bla a2 LEFT OUTER JOIN bla a3 etc. If you want all friends out to some specified distance n where n > 1, recursive CTEs are a much more sane solution that anything involving n levels of OUTER JOINs. And if you just want specifically friends-of-friends-of-friends by joins, you want three levels of INNER JOINS. > With a graph DB, you still only have 1 copy of each person - you are just storing the 'joins' or ids/addresses of the 'rows' you want to join with ahead of time. More accurately, graph DBs store addresses (not ids/addresses) while RDBMS store ids (Foreign Keys) of the records you want to join with ahead of time. This means that to get from one record to a related record takes an additional level of indirection in an RDBMS compared to a graph database, but that doing so from many similar structured records to their equivalent linked records is more efficient in an RDBMS. > Another nice part of a graph db is if you have a large collection of different objects in your programming language that all interact with each other. Those interactions can be stored directly in-line and allow for an ORM layer to be more efficient when retrieving the whole collection. With a Graph DB instead of an RDBMS, you obviously wouldn't haven a ORM (Object-Relational Mapping) layer in any case. At more than one level out

RyanZAG 13y ago
Recursive CTEs are not what one would traditionally call 'relational' and many relational databases certainly don't have them. Some distributed graph databases do store ids and not addresses - there is no actual requirement that they be addresses, only that they be efficient to retrieve. So not actually more accurate. People still call object-db mappers 'ORMs' even when dealing with document databases such as Google's bigtable or MongoDB. It's just an acronym at this point. [1][2] [1] - http://mongomapper.com/ http://mongomapper.com/ [2] - https://code.google.com/p/mongo-java-orm/ https://code.google.com/p/mongo-java-orm/ EDIT: By 'id' I'm referring to some unique hash or key that can be used to locate a document. By 'address' I'm referring to an actual on-disk location that can be directly loaded. Maybe my definitions clash with yours, I don't think this stuff is formally defined.
- dragonwriter 13y ago
  > Recursive CTEs are not what one would traditionally call 'relational' I'm not a big fan of tradition for its own sake. > and many relational databases certainly don't have them. The only major SQL-based RDBMSs I can think of off the top my head that don't support recursive CTEs in their current version are SQLite and MySQL -- Postgres, Firebird, DB2, Oracle, and MS SQL Server all do.