What are the appropriate scenarios for graph-based databases

6

Lately I've been studying the graph-based Neo4j database.

Given that the vast majority of current applications use traditional relational databases, I ask:

  • What are the appropriate scenarios for using this type of database?
  • What would be the main pros and cons?
  • In the national (Brazilian) scenario, is this type of database compatible with production scenarios?
asked by anonymous 21.09.2017 / 02:58

2 answers

2

None: P

Of course there is. The point is that it is possible to use the relational database to make graphs since these are at a level above the relational and increasingly the main database software will provide facilities to deal with knots and edges, but are only facilities , they are not required.

These databases do marketing that have better performance, but this is just a matter of organizing the data. It has no miracle, it's like NoSQL, it's fast under certain circumstances giving up something to be quick.

People often use it without realizing it, but in general the scenarios are limited since it is useful in cases of data completely without structure that need to be formed according to the need without much criterion, which is rare. Generally, rather complex scientific problems are those with very open processes, possibly involving the learning machine, artificial intelligence, neural networks, etc.

The only great advantage of the graph-specific database is the ease of handling this format since everything it offers in thesis can be done in other databases with a minimum of resources or a low enough level to simulate everything in hand. I read about advantages and they only exist for the organization, not the software itself. Of course, simulating a graph in a relational database tends to be harder, especially if you want the same performance and it's easier to make mistakes.

When you want to do something that is different from a graph, it has enormous difficulty or impossibility. It does not have transactions and the facilities that queries that the relational offers.

I read about advantages that are actually characteristic of specific software rather than the model.

The secret to his performance is to use data pointers, something you only create in your tables. It is not magic, it is just a basic technique and even very simple for those who understand the fundamentals of computing.

Brazil is not an island, as it has been used outside, it has here, but it is still very limited. It will continue being with the adhesion of the relational to this modality, after all it is common that only part of the problem benefits from the graphs, other parts still will benefit from relational and other forms, then a system that does not cling to a form tends to have more success .

Understand that the relational was not as successful at all. Most of the concurrent modes exist for decades too and do not make such great success because they are not as useful in many scenarios as the relational is. Even NoSQL seems to be successful now, if you talk more than you use. And if you use more than you should. There are many cases that is an equal or worse option to relational, but the fad makes it adopted.

The success of many new things is because people only follow cake recipes and do not understand how to solve problems with the tools that already exist. So in fact what brings success is having something ready for people to use and not new capabilities.

    
26.09.2017 / 13:20
-3

What are the appropriate scenarios for using this type of database?

Senators where performance is needed and where data is not organized. A legal reference to this is BigData .

What would be the main pros and cons?

The first question answers the second question. There are no pros or cons, there is misuse of technology. I recommend link

In the Brazilian (national) scenario, is this type of database in production scenarios?

I do not know companies that use in production and with 100% of use. But if the scope asks, I see no problem using it.

    
26.09.2017 / 13:49