4 ms·

> Does this need to be tabular data? No, not a requirement. But what will I lose if I choose graph DB over RDBMS?

by m33k44 7y ago

phpnode 7y ago
From experience, so many things that graph dbs are not worth the effort in something like 99% of cases. Stick with postgres or similar if you can!
asark 7y ago
Familiarity, tons of features, existing well-worn supporting libraries for lots of languages and ecosystems, and depending on which one also safety/reliability and, for a variety of common query patterns including many that look pretty damn graphy, performance and predictability. FWIW my experience is with Neo4j.
henryfjordan 7y ago
Graphdbs are excellent at joins when a relationship exists (they are O(1), not O(logn) like SQL). The query language many of them use (Cypher) is very expressive for these types of queries. Take a look, the basics are very easy to pick up. The biggest draw-back is that you likely already know SQL and would need to learn a lot up front. The resources out there are good, but there are so many more good SQL references. If you want to do aggregations and the like, SQL Databases might be a little more suited for those tasks. Popular SQL DBs are also a lot more stable and optimized, just given their age. To make use of these features though, all your data must fit on one box.
- mcv 7y ago
  The difference in experience is really the only major downside to graph DBs. They're an excellent tool for many of the situations where we currently use RDBMSs, mostly because that's what we're familiar with while graph DBs are new and unfamiliar. I've now been using Neo4J for a couple of months, and I don't want to go back. If relations between different items are what matters to you, then graph DBs make that so painless compared to the joins from relational DBs. The main thing relational DBs still have over graph DBs is tables. Give me a table with all items from this table that meet this condition. Graph DBs can do that too, but it's less natural, because they don't store their data in tables, and nothing guarantees that all items of a certain type actually have the same properties. RDBMSs are statically typed, Graph DBs dynamically typed.

> Does this need to be tabular data? No, not a requirement. But what will I lose if I choose graph DB over RDBMS?

by m33k44 7y ago

> Does this need to be tabular data? No, not a requirement. But what will I lose if I choose graph DB over RDBMS?

From experience, so many things that graph dbs are not worth the effort in something like 99% of cases. Stick with postgres or similar if you can!

asark 7y ago

Familiarity, tons of features, existing well-worn supporting libraries for lots of languages and ecosystems, and depending on which one also safety/reliability and, for a variety of common query patterns including many that look pretty damn graphy, performance and predictability. FWIW my experience is with Neo4j.

henryfjordan 7y ago

Graphdbs are excellent at joins when a relationship exists (they are O(1), not O(logn) like SQL). The query language many of them use (Cypher) is very expressive for these types of queries. Take a look, the basics are very easy to pick up. The biggest draw-back is that you likely already know SQL and would need to learn a lot up front. The resources out there are good, but there are so many more good SQL references. If you want to do aggregations and the like, SQL Databases might be a little more suited for those tasks. Popular SQL DBs are also a lot more stable and optimized, just given their age. To make use of these features though, all your data must fit on one box.

mcv 7y ago
The difference in experience is really the only major downside to graph DBs. They're an excellent tool for many of the situations where we currently use RDBMSs, mostly because that's what we're familiar with while graph DBs are new and unfamiliar. I've now been using Neo4J for a couple of months, and I don't want to go back. If relations between different items are what matters to you, then graph DBs make that so painless compared to the joins from relational DBs. The main thing relational DBs still have over graph DBs is tables. Give me a table with all items from this table that meet this condition. Graph DBs can do that too, but it's less natural, because they don't store their data in tables, and nothing guarantees that all items of a certain type actually have the same properties. RDBMSs are statically typed, Graph DBs dynamically typed.