3 ms·

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 optimizat

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 11y ago
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.

jexp 11y ago

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.