undefined | Better HN

0 pointsmcv6y ago0 comments

You don't need scale to make graph databases useful. As soon as relationships between items are more important than the data within a table, graph databases make your data easier to navigate than joins upon joins.

0 comments

4 comments · 3 top-level

maayank6y ago· 1 in thread

I feel like I’m taking imagination-b-gone pills. The only potential uses off the top of my head that I’ve witnessed are credentials management and financial instruments arbitrage, and in both cases it was solved well by other measures.

I’m sure there are projects where it’s useful, but not “every company” useful like SQL or even a server supervisor framework. I would be happy to be proven wrong.

mcvOP6y ago

I've got a friend who claims that nearly everything you can do with SQL, you can do easier with a graph database. I'm not sure that's true; as long as you need only one or two tables at a time, and/or automatic validation against the database schema is vitally important for you (that's probably the big one), then SQL databases are probably still better. But as soon as relations start to matter, and the number of joins in your queries starts to grow, a graph database becomes much nicer to use.

balfirevic6y ago

Is it so substantially easier to justify keeping (and maintaining) another copy of your data in the second database? Or, alternatively, to keep your data split between several different databases and invest all the required effort to keep them consistent?

Sometimes it is, of course. But not often.

jimbokun6y ago

Any concrete examples of these kinds of data management problems where graph databases are a good fit?

j / k navigate · click thread line to collapse