
Ask HN: Why not use Graph DBs as a general purpose DB? - rottyguy
Am investigating some db technologies for an application I&#x27;m working on and just came across Graph DBs (note I&#x27;m not a db guy). Just playing around a bit with neo4j&#x27;s online REPL felt a little more natural to model out data. However, as I dig into it, people seem to take the stance of GDB being particularly well suited for certain applications but stick with Relational where possible. Is this mentality more about Relational being much more widely adopted in society today (and thus more tested, optimized, understood, etc.) as opposed to some deficiency in modelling problems with graphs (I&#x27;m inclined to make a comparison between functional language vs object oriented vs procedural programming languages where thinking in Graphs these days causes a bit of a mental shift and therefore dissuaded b&#x2F;c it &quot;feels&quot; different -- much like going from C (procedural) to C++ (oo) and now C++ (oo) to F# (functional) )<p>For example, if we just take a simple case: Modelling out a Restaurant Menu that serves Breakfast, Brunch (on Weekends), Lunch, Dinner, Desserts, Drinks, I can see both GDB and Relational being able to solve the problem but why would I necessarily choose Relational over GDB (or vice&#x2F;versa)?
======
amirouche
Because graphdb are not good at listing/scanning single types e.g. Lunch,
Dessert, Drinks, etc. Simple queries have similar complexity but there is no
optimization for the mildly complex queries:

> SELECT COUNT(drink.id) FROM lunch, drink WHERE lunch.id == drink.lunch_id
> ORDER BY lunch.delivery_date, lunch.total_price

Everything that is not recursive is better served by RDBMS.

My understanding is that it's not that it's impossible to optimize the RDBMS
usecase in graphdb implementation but that it's difficult in terms of query
language to express both the traversal and scan. Arangodb want to be tackle
that area through AQL.

You can also build somekind of graphdb schema, a specific graph topology that
alleviate the need for specific optimization by basically denormalizing the
schema.

> I'm inclined to make a comparison between functional language vs object
> oriented vs procedural programming languages

IMO tinkerpop and neo4j looks like Python (dynamic oo and functional language)
vs Java (static typed and class based) which look like RDBMS. ArangoDB and
OrientDB (multi-model) looks like Scheme Guile.

Even if graphdbs have weakness, like dynamic programming, they allow to build
things more quickly.

> where thinking in Graphs these days causes a bit of a mental shift and
> therefore dissuaded b/c it "feels" different

Yes definitely. That said from my point of view, it's clear where a graphdb
"is the right tool for the job" whereas functional programming is a writing
style that can be applied to procedural or OO languages; It's not clear what's
the pragramatic purpose of purely functional language.

~~~
jexp
Your query actually doesn't make sense as you can't aggregate and then sort by
something that's not returned. :)

I mean expressing this is easy and the execution is also straightforward, e.g.
in Neo4j:

MATCH (lunch:Lunch)<-[:PART_OF]-(drink:Drink) RETURN lunch, COUNT(drink) ORDER
BY lunch.delivery_date, lunch.total_price

this would be a more efficient variant:

MATCH (lunch:Lunch) RETURN lunch, size((lunch)<-[:PART_OF]-()) as drinks ORDER
BY lunch.delivery_date, lunch.total_price

So I don't agree with the statement, that everything which is not recursive is
better served by and RDBMS.

There is more than one use-case for your data most use-cases in real
applications are more than mildly complex.

And GraphDBs might not be much faster on those types of queries but they are
also not tremendously slower.

