RDBMS and Graph Database both use different approaches to store and retrieve data. The following table specifies the differences between them:
The Graph Data Model
First things first! To decide if you need a graph database, you need to be familiar with the basic terminology. The fundamental components of a graph database are:
Nodes - the main entities in a graph. You can think of them as rows in a relational database.
Relationships - the connections between those entities. These would be foreign keys in a relational database.
Labels - attributes that group similar nodes together.
Properties - key/value pairs stored within nodes or relationships.
In a typical social network graph, the nodes represent people in different social groups and their connections with one another. Every person is represented with a node that’s labeled as Person. These nodes contain the properties name, gender, location and email. The relationships between people in this network are of the type FRIENDS_WITH and contain a yearsOfFriendship property to specify the duration of the friendship connection. Each person is assigned a location through :LIVES_IN relationships with nodes labeled Location.
The Graph Data Model
While this is a very simple example, it concisely demonstrates the power and benefits of using a graph database. For example, you could easily add different properties to some of the nodes if you wanted to. Unlike a table, where you need to add a column for each additional attribute, here you can be much more flexible with the data structure and types. A property that was meant to be a string can be used as an integer without any constraints. To be fair, this can cause problems for you in the long run, but you can do it if need be.
The Relational Data Model
A relational database requires a predefined and carefully modeled set of tables. We create one for each entity and add the needed attributes as columns. While this is also pretty straightforward, it’s much more rigid than the graph schema and not as extendible.
For example, each person is connected to other people through friendships, and to model this relationship, we have to add another table. If there were different kinds of connections (related to, no longer friends…) we would have to change the schema accordingly. A relational database isn’t suited for this specific use case because the focus isn’t on the data itself but rather on the relationships within it.
