You might be wondering what is so special about Graph databases that everyone is talking about those?
Well, who would not when there is a data model which actually focuses on the connection between two data points (edges/relationships) and not just the data points which are actually just the entities. Or we can say vertices in the context of graph databases.
Our relational databases, as we have seen get very complex when there are a lot of relationships with different entities involved. And this is the scenario when we like to consider graph databases.
So imagine a scenario where you have multiple many-to-many relationships and you need to communicate through using excessive JOINs inside your relational database. A better idea here is to avoid so many JOIN operations and use a Graph Database.
Now, this is one basis for choosing to use a Graph database. Let us look at some other scenarios. Graph Databases are best to use social network type of setup where different entities need to communicate with each again making it a many-to-many kind of relationship. Functionalities like choosing a person, showing their friend list, recommending what you looked at in the past, recommending what your friends like and you don’t yet, and so on.
This not only applies to the virtual examples but the real-life ones too. For example, a college annual festival where there are multiple entities and relationships between each one of those.
In this small blog post, we quickly saw the different scenarios when there is a need to use the graph databases and what special features it adds to the implementation that makes it better to work with Graph databases when working with many-to-many relationships.