3 ms·
Ask HN: Why not use Graph DBs as a general purpose DB?
Am investigating some db technologies for an application I'm working on and just came across Graph DBs (note I'm not a db guy). Just playing around a bit with neo4j'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'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/c it "feels" different -- much like going from C (procedural) to C++ (oo) and now C++ (oo) to F# (functional) )
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/versa)?
- amirouche 11y agoBecause 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 11y agoYour 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.