4

To me, relational data is a graph, where each table is a node, and each foreign key is an edge connecting the two nodes together.

So when I hear about things like Neo4j and "graph databases", it is difficult for me to understand how they are inherently different from a relational model, which is already itself a graph!

Most important, because I can't tell the difference between the two, it's difficult for me to figure out which problem domains are best solved with a graph model, and which ones are best solved with a relational model. I'm looking for a set of guidelines to say: Hey, this problem is definitely best represented by a graph model, so I will use (say) Neo4j. Or, to say: This problem is definitely best represented by a relational model, so I will use (say) MySQL.

Edit: In summary, what problem domains (data-wise) do graph models solve better than relational models?

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756

3 Answers3

-1

one of the cases you would want to use neo4j instead of relational DB:

as soon as you are using mostly several joins between tables, especially when joining a table on itself, consider using graph DB.

in my eyes using a graph DB is a method to store those kind of information, which i'm querying in very few ways (or maybe i'm using just one pattern of query) and i'm looking for the speed of the answer. having relational DB is better when you use plenty query types and still have plenty of computational power.

if you would like to know more and go deeper into graph DB, i suggest you to read smthing about math graphs in general (http://en.wikipedia.org/wiki/Graph)

ulkas
  • 5,748
  • 5
  • 33
  • 47
  • of course neo4j serves primary for large data sets (~bilions primitives) and thus it is worthless building a typical web site on it. – ulkas Jul 17 '12 at 15:41
  • Actually it's equally good for typical websites...I don't think it suites only large data sets. – Luanne Jul 17 '12 at 17:35
  • 1
    In the last paragraph, you could tone down the patronizing assumption that your reader doesn't and couldn't understand what a graph is. – jameshfisher Oct 10 '14 at 16:46
-1

As you said Graph and Relational DB may look same in structure if you compare node with rows and relations with table and properties with columns.

But basic difference is how we access the data.

You can connect two nodes with a relation and add a label to it and easily find if they are related rather than using foreign key (that would make it slower if you have lot of data in a table).

Use Graph DB for maintaining relations and additional information about that nodes (that are related) in RDBMS. You can use both of them in single app if app has the requirement.

user2756260
  • 160
  • 1
  • 9
-1

In a nutshell, "graph" means "recursive". You need graphs when you want to process your data recursively after arranging as:

struct node {
     *node[] edges;
}

or, alternatively, as a matrix of connections:

  | a | b | c |
--------------
a | x |   |   |
b |   | x |   |
c |   |   | x |

Examples of such algorithms are Dijkstra and Gradient descent.

user46748
  • 145
  • 2
  • 4