Honestly, i think graph db being more powerful is one of their more reasonable claims. Graph db trade off a more flexible data model (which some people would call power) against performance/scalability.
Whether or not that's a good trade off in your domain is a very different question.
Edit: although based on the docs, the graph db seems roughly a data structure where nodes can point to each other (i dont see anything about complex queries, or managing concurrency, or even persistence). By that definition, i think even c would be a language with an embedded graph db (structs and pointers)
Neo4J has a souped SQL language they call Cypher to perform queries. But since Beads data structures are typically arranged in tree form, one typically uses the loop construct to interate across them, as one is often drawing them. To that end, Beads has a fairly elaborate loop construct, with the ability to traverse 1 or 2 dimensions at once, or do a recursive descent traversal.
In a graphical programming environment one is really listing and drawing the content for editing, versus making a list of something.
You can send subtrees across the wire conveniently, subscribe to a remote machine's subtree, etc. and you can write to the hard drive the trees.
However concurrency is not really present in the system as i am emitting JS which is a single threaded system for the most part. So Beads has almost zero concurrency support at present.
> Honestly, i think graph db being more powerful is one of their more reasonable claims. Graph db trade off a more flexible data model (which some people would call power)
You can represent graphs in the relational model so that’s simply bullshit.
Neo4j had a great demo, load up the IMDB database, then solve six degrees of Kevin Bacon with SQL vs with Cypher. The Cypher is a one liner that runs immediately, the SQL is a mess that almost brings down the database.
For certain types of queries, recommendation engines being a prime example, graph databases are awesome.
For one, Neo4j is an implementation and SQL is not. As for clarity, SQL, although by far the most widespread query language is a shitty language in many respects... again a separate issue from the relational model.
In any case you’re conflating a storage engine and a query language. There’s no reason an RDBMS implementation cannot be tuned for graphs, and there is no inherent lack of generality in the relational model which seems to be the prior posters claim. Whether Neo4j is a useful piece of software is a different topic.
Infinite self-joins are not elegant in relational algebra. They are very not elegant in SQL (recursive CTE's are soo ugly). Last of all, they are super inefficient in almost every RDBMS.
> Infinite self-joins are not elegant in relational algebra.
Somewhat ironic comment given the name of this site.
SQL stinks as a language in many ways, won’t argue there. However for many cases even PostgreSQL does just fine with recursive CTEs (though granted when it fails it does so hard). Oracle does better (and CONNECT BY has been around for over 40 years - someone’s been getting by with it). Graphs in RDBMSes are not uncommon.
Anyway, none of this has anything to do with the original claim. Are graph db implementations useful? Definitely (though often times sticking with the rdbms is the better choice). But they get their utility by being less flexible.
Whether or not that's a good trade off in your domain is a very different question.
Edit: although based on the docs, the graph db seems roughly a data structure where nodes can point to each other (i dont see anything about complex queries, or managing concurrency, or even persistence). By that definition, i think even c would be a language with an embedded graph db (structs and pointers)