3 ms·

Reason #1: Relational DBs got a simple query language, which boosted their popularity in 1980s. MS Access made it a funny game, and you could get it going in un

Reason #1: Relational DBs got a simple query language, which boosted their popularity in 1980s. MS Access made it a funny game, and you could get it going in under an hour. I had experience with Wikidata, and it was way harder. The logic of the language is impossible to figure out by reading the examples. (My request was simple like "get region X, find all nested entities and their population".) I'm not familiar with other query languages to Graph DBs, but if this is state of the art, I'd avoid it. Reason #2: Graphs are not easier to reason about. When you have all properties as optional, and every connection (edge) gets a set of properties too, things become much harder. "John is Frank's father" in that database would be a very complex structure: entity A which is John with properties such as "belonging to a class of" humanity (which is another entity), human own first name, last name, and finally a "child" property, linking to Frank, who's got same set of attributes. That's hard to put in your head. With relational DB for this example, you have to imagine just a 4*2 table (3 if we count the header). I think these 2 factors make development with graph DBs much harder, and developers resort to them only when absolutely necessary, and keeping only a single type of relations in graph (like road graph, or parent-child relationship).

CameronNemo 5y ago
You don't use properties to point to other entities/nodes in a property graph. That is what edges are for. So you could have an edge of type father, or maybe a "parent" type edge and the properties on that edge denote further details like whether it is biological or legal, et cetera.
- culebron21 5y ago
  You're right, I don't remember the terminology well. And yes, I remember edges having these properties as well. This made me think that graphs are essentially more complex. With a simple relational DB what you have essentially is a table/mapping/dictionary-like structure. (Even when storage is columnar, the API is still behaving like a table/map/dict.) With a graph, if we only keep the info about edges, it also becomes a key=>value map, where key is node A & B list/set, and values are edge properties. But as soon as we try storing info about nodes, this requires a second table. Wikidata has to make yet another table, with types of edges and nodes.

CameronNemo 5y ago

You don't use properties to point to other entities/nodes in a property graph. That is what edges are for. So you could have an edge of type father, or maybe a "parent" type edge and the properties on that edge denote further details like whether it is biological or legal, et cetera.

culebron21 5y ago
You're right, I don't remember the terminology well. And yes, I remember edges having these properties as well. This made me think that graphs are essentially more complex. With a simple relational DB what you have essentially is a table/mapping/dictionary-like structure. (Even when storage is columnar, the API is still behaving like a table/map/dict.) With a graph, if we only keep the info about edges, it also becomes a key=>value map, where key is node A & B list/set, and values are edge properties. But as soon as we try storing info about nodes, this requires a second table. Wikidata has to make yet another table, with types of edges and nodes.