Graphical and relational data models

Question

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

So, when I hear about things like Neo4j and “graph databases”, it’s hard for me to understand how they essentially differ from the relational model, which itself is already a graph!

Most importantly, because I can’t tell the difference between them, it’s hard for me to understand which problem domains are best solved using a graphical model and which are best solved with a relational model. I am looking for a set of recommendations to say: Hey, this problem is definitely best represented by the graphics model, so I will use (say) Neo4j. Or, saying: this problem is definitely best represented by the relational model, so I will use (say) MySQL.

Change In general, which problem domains (according to data) model graphs better than relational models?

Answer 1

one of the cases when you want to use neo4j instead of a relational database:

as soon as you , using basically several connections between tables, especially when connecting to a table , consider using a DB graph.

in my eyes, using the DB graph is a method of storing such information that I refer to very little (or maybe I use only one sample request), and I'm looking for the speed of response. having a relational database is better when you use many types of queries and still have sufficient processing power.

if you want to learn more and delve into graphical DB, I suggest you read smith about mathematical graphs in general ( http://en.wikipedia.org/wiki/Graph ), but it can be too difficult to understand alone if you don’t have strong mathematical background.

Answer 2

The main difference is how information is stored, and therefore how they are available upon request.

As you said, a chart can also be saved in a relational model, but if you want to cross a chart, you usually need to join multiple tables. In this case, the model diagram, as in InfiniteGraph, works better because it stores the relationships of the object in the entity itself. This means that walking in relationships is a quick and cheap operation.

Now you have asked which graphic problem databases are best suited. If your problem is looking for relationships that are not directly known between objects or that do not find all the known information for a single object across several relationships, you may need to examine graphical databases.

Objectivity, Inc., a companion behind InfiniteGraph, has some nice use cases and interactive demos you can take a look at (http://objectivity.com/resources). Thinking about how to solve the LinkHunter demo with a relational database in a controversial time can help you understand graph databases.

In the end, I want to say that graphical databases are generally not the best relational databases. If your problem is solvable in a relational database, you should accept this. See Graphic Databases more than an easy way to solve problems; relational databases have not been created.

Regards Timo

Answer 3

Perhaps you can even look at http://docs.neo4j.org/chunked/snapshot/what-is-a-graphdb.html and http://docs.neo4j.org/chunked/snapshot/data-modeling-examples. html , with comparison http://docs.neo4j.org/chunked/snapshot/examples-from-sql-to-cypher.html

Answer 4

As you said, a diagram and a relational database can look the same in the structure if you compare node with rows and relations with a table and properties with columns.

But the main difference is how we access the data.

You can connect two nodes with a relation and add a label to it and easily find whether they are connected and not use a foreign key (to slow down if you have a lot of data in the table).

Use the DB column to maintain relationships and additional information about these nodes (associated with them) in the RDBMS. You can use both of them in one application if the application has this requirement.