3 ms·

We've had this discussion before but that product is not a graph database, it has no graph traversal features

by phpnode 11y ago

marknadal 11y ago
Dijkstra's algorithm is wonderful, but by no means is a requirement for being a graph database. A graph database is that, a database composed of nodes that can interconnect into a graph. GUN supports this and allows for traversing the graph. We haven't implemented Dijkstra's algorithm, which is what your "discussion" refers to.
- phpnode 11y ago
  We've never talked about Dijkstra as far as I recall. Your product doesn't support graphs any more than, say, mongodb does because ultimately all you are doing is loading an object from JSON and then sending it to the consumer. This is in contrast to true graph databases whose main selling point is their ability to efficiently traverse, filter and aggregate large graphs to find the answer to some question, and then send the answer to the consumer. Gun doesn't meet anyone's definition of "graph database" other than your own. If I load some JSON from a URL, and use lodash to pluck some data out of it, is it a graph database?
  - marknadal 11y ago
    Dijkstra was your complaint about shortest path. GUN can do efficient traversal and filtering, and this is going to be even better in our 0.5.x release with lexical cursor support. By "anyone" do you mean Wikipedia's? https://en.m.wikipedia.org/wiki/Graph_database https://en.m.wikipedia.org/wiki/Graph_database , because GUN does match its definition. Although we haven't implemented Dijkstra's. I'm out in France right now and just boarded a plane to Slovenia, so I won't be able to reply again. Have a good one.
  - sklogic 11y ago
    Are you inventing your own new, hipstor definition of a "graph database" here? I used graph databases a lot, and I never heard of any of the requirements you've listed.
    - phpnode 11y ago
      Not at all but maybe I'm not being clear. My definition of "graph database" is "a database which can efficiently represent graphs and offers functionality for traversing them, in order to allow queries such as 'find the business relationships between user X and user Y based on who they've worked with' (ala linkedin)" This is not what gun does. It alternately calls itself "the simplest database out there", "not a database" and "a distributed cache". It provides a mechanism for sharing a list of objects across multiple peers, but must transfer all of the data to each peer. It is conceptually similar to downloading a large chunk of JSON from a server and using lodash, ramda etc to query it, but no one would call that a graph database.
      - sklogic 11y ago
        > a database which can efficiently represent graphs and offers functionality for traversing them First part is matching the commonly accepted definition (the one that had been around for about 50 years). The second part is your own invention. > This is not what gun does I did not even have a chance to take a look at that product yet. So far I'm just puzzled by the graph database definition some people seem to be using in this thread.
        phpnode 11y ago
        perhaps this is a terminology issue, I'll admit that I'm too young to have used pre-relational graph databases, but presumably they have a way of navigating / jumping between documents/vertices, (presumably based on pointers), otherwise what point would there be in having a graph? I'd encourage you to look at the product and see whether it meets your definition.
        sklogic 11y ago
        Yes, of course you could always select a node (often you'd always have to start from a single root node), select arcs, filter the arcs by some criteria, etc. But I've never seen a complex query language that would allow to express any complex traversal strategies (like Dijkstra algorithm), and from your wording I concluded that this was your requirement for something to be called a graph database.
sklogic 11y ago
Mind naming any historical (i.e., from the pre-relational era) graph DBMS that had graph traversal features?

We've had this discussion before but that product is not a graph database, it has no graph traversal features

by phpnode 11y ago

We've had this discussion before but that product is not a graph database, it has no graph traversal features

Dijkstra's algorithm is wonderful, but by no means is a requirement for being a graph database. A graph database is that, a database composed of nodes that can interconnect into a graph. GUN supports this and allows for traversing the graph. We haven't implemented Dijkstra's algorithm, which is what your "discussion" refers to.

phpnode 11y ago
We've never talked about Dijkstra as far as I recall. Your product doesn't support graphs any more than, say, mongodb does because ultimately all you are doing is loading an object from JSON and then sending it to the consumer. This is in contrast to true graph databases whose main selling point is their ability to efficiently traverse, filter and aggregate large graphs to find the answer to some question, and then send the answer to the consumer. Gun doesn't meet anyone's definition of "graph database" other than your own. If I load some JSON from a URL, and use lodash to pluck some data out of it, is it a graph database?
- marknadal 11y ago
  Dijkstra was your complaint about shortest path. GUN can do efficient traversal and filtering, and this is going to be even better in our 0.5.x release with lexical cursor support. By "anyone" do you mean Wikipedia's? https://en.m.wikipedia.org/wiki/Graph_database https://en.m.wikipedia.org/wiki/Graph_database , because GUN does match its definition. Although we haven't implemented Dijkstra's. I'm out in France right now and just boarded a plane to Slovenia, so I won't be able to reply again. Have a good one.
- sklogic 11y ago
  Are you inventing your own new, hipstor definition of a "graph database" here? I used graph databases a lot, and I never heard of any of the requirements you've listed.
  - phpnode 11y ago
    Not at all but maybe I'm not being clear. My definition of "graph database" is "a database which can efficiently represent graphs and offers functionality for traversing them, in order to allow queries such as 'find the business relationships between user X and user Y based on who they've worked with' (ala linkedin)" This is not what gun does. It alternately calls itself "the simplest database out there", "not a database" and "a distributed cache". It provides a mechanism for sharing a list of objects across multiple peers, but must transfer all of the data to each peer. It is conceptually similar to downloading a large chunk of JSON from a server and using lodash, ramda etc to query it, but no one would call that a graph database.
    - sklogic 11y ago
      > a database which can efficiently represent graphs and offers functionality for traversing them First part is matching the commonly accepted definition (the one that had been around for about 50 years). The second part is your own invention. > This is not what gun does I did not even have a chance to take a look at that product yet. So far I'm just puzzled by the graph database definition some people seem to be using in this thread.
      - phpnode 11y ago
        perhaps this is a terminology issue, I'll admit that I'm too young to have used pre-relational graph databases, but presumably they have a way of navigating / jumping between documents/vertices, (presumably based on pointers), otherwise what point would there be in having a graph? I'd encourage you to look at the product and see whether it meets your definition.
        sklogic 11y ago
        Yes, of course you could always select a node (often you'd always have to start from a single root node), select arcs, filter the arcs by some criteria, etc. But I've never seen a complex query language that would allow to express any complex traversal strategies (like Dijkstra algorithm), and from your wording I concluded that this was your requirement for something to be called a graph database.

sklogic 11y ago

Mind naming any historical (i.e., from the pre-relational era) graph DBMS that had graph traversal features?