3 ms·

Sadly it talk against "Relational databases" instead of "RDBMS implementations". The relational model is incredible powerfull. Maybe graphs need something seri

by mamcx 8y ago

Sadly it talk against "Relational databases" instead of "RDBMS implementations". The relational model is incredible powerfull. Maybe graphs need something seriously specializes (and indexes, of course) but the relational model do fine: - Relational - Key-value - Document - In-memory - Search In fact, a index (that is the thing that need to be fit for the case) can be modeled as key-value, so, as relational. Relational won agains the NoSql in the past because is MORE powerfull, flexible. --- What need to change, is the specifics of the implementations. And yet, relational adapt fairly easy. In fact, just look how many stores add a sql-layer on top. Ironically, SQL is what need a easy makeovers, no the relational model....

qop 8y ago
I think there are times when the graph model shines. https://theburningmonk.com/2015/04/modelling-game-economy-with-neo4j/ https://theburningmonk.com/2015/04/modelling-game-economy-wi... I read this article I found on HN a few years ago, and for some reason it came to my mind just now. The neat thing about the graph model of course is being more immediately expressive to the query-er, and that takes cognitive load away from that person. I'll never say a bad thing about SQL or the relational model. I completely agree that it's superior in terms of flexibility, performance (almost always), modelling (usually), etc but I guess there are times where you have a weird project and it's just I guess the convenience and ease of using Neo4j and a few cypher queries and then it's over. In the case of the article I linked, there is also the benefit of having a convenient way to see how changes echo throughout the graph, something that is more involved to do with tables and joins and all that. I'm not a DBA, I've really only ever dabbled, but if I got dropped into that situation and DIDN'T have a graph model, I'd have no clue where to even start. Maybe I'd start trying to walk tables and build graphs out from each item type to each other item type. That'd be gross. Of course, that's probably not a problem scenario that comes up very often. Most of the times I've interacted with databases in general I've been just dealing with sanitizing params, getting HTTPS configurations configurated, just boring infosec stuff. That problem is probably very rare in the realm of "problems that graph seems to have an advantage" Anyways, yeah. Relational, awesome. Graphs, sometimes convenient.
smadge 8y ago
True, a graph is a relationship between vertices, a key/value store is relationship between keys and values, etc. Relations (sets of ordered n-tuples) remain the theoretical way we reason about data.

by mamcx 8y ago

qop 8y ago

I think there are times when the graph model shines. https://theburningmonk.com/2015/04/modelling-game-economy-with-neo4j/ https://theburningmonk.com/2015/04/modelling-game-economy-wi... I read this article I found on HN a few years ago, and for some reason it came to my mind just now. The neat thing about the graph model of course is being more immediately expressive to the query-er, and that takes cognitive load away from that person. I'll never say a bad thing about SQL or the relational model. I completely agree that it's superior in terms of flexibility, performance (almost always), modelling (usually), etc but I guess there are times where you have a weird project and it's just I guess the convenience and ease of using Neo4j and a few cypher queries and then it's over. In the case of the article I linked, there is also the benefit of having a convenient way to see how changes echo throughout the graph, something that is more involved to do with tables and joins and all that. I'm not a DBA, I've really only ever dabbled, but if I got dropped into that situation and DIDN'T have a graph model, I'd have no clue where to even start. Maybe I'd start trying to walk tables and build graphs out from each item type to each other item type. That'd be gross. Of course, that's probably not a problem scenario that comes up very often. Most of the times I've interacted with databases in general I've been just dealing with sanitizing params, getting HTTPS configurations configurated, just boring infosec stuff. That problem is probably very rare in the realm of "problems that graph seems to have an advantage" Anyways, yeah. Relational, awesome. Graphs, sometimes convenient.

smadge 8y ago

True, a graph is a relationship between vertices, a key/value store is relationship between keys and values, etc. Relations (sets of ordered n-tuples) remain the theoretical way we reason about data.