I used Neo4j for a few side projects but my go-to is still PostgreSQL. The largest flaw I see with Neo4j (and probably other graph databases as well) is that it forces you to think of your entities as either vertices or edges and that line tends to be not as clear as you might expect.
For example: (:Person)-[:BEFRIENDS]->(:Person)
If we'd want to store a date with that relationship, Neo4j got your back, that's entirely possible (= relationships can have attributes). But now our requirements change and we'd also want to have an entity for Events shared by friends (e.g. friendship anniversary), now we have to remodel our data to something like:
So I feel like the vertice/edge distinction Neo4j makes, gets in the way of changing data model needs and I ultimately think that modeling your data as a graph is not helpful. Though it can be extremely helpful in querying and that's where its biggest strength lies.
The problem you're describing is mostly attributable to property graph stores, and doesn't apply to named graph engines.
This is the essential difference between neo4j (a property graph engine) and most RDF stores which support quads (i.e. <subject> <predicate> <object> <context>)
I see what you mean. And yet strangely, the need for that "Friendship" node can also be seen as a strength. How else would you assert metadata about that thing otherwise?
If A and B share an event via a friendship, you can keep track of things about that. Granted in an RDBMS if all you wanted was to draw the line then you could do it with an extra FK, but I think the conclusion you're drawing is going too far, specifically:
> In SQL that wouldn't have been a remodel, because there's no difference between a relationship and an entity
There is a difference in SQL; relationships are EITHER more columns, OR a join to another table, both are possible. In graphs, "hyper relationships" (e.g. relating more than 2 things) require another node, but this is apples/oranges comparison.
I probably should've clarified that I was talking about n:m-relationships. And for that case I don't see how it would've been an apples/oranges comparison.
For example: (:Person)-[:BEFRIENDS]->(:Person)
If we'd want to store a date with that relationship, Neo4j got your back, that's entirely possible (= relationships can have attributes). But now our requirements change and we'd also want to have an entity for Events shared by friends (e.g. friendship anniversary), now we have to remodel our data to something like:
(:Person)-[:IS_IN]->(:Friendship)-[:HAS]->(:Event)
In SQL that wouldn't have been a remodel, because there's no difference between a relationship and an entity. We would've gone from:
Person(id) Friendship(person1_id, person2_id)
to:
Person(id) Friendship(person1_id, person2_id) Event(friendship_id)
So I feel like the vertice/edge distinction Neo4j makes, gets in the way of changing data model needs and I ultimately think that modeling your data as a graph is not helpful. Though it can be extremely helpful in querying and that's where its biggest strength lies.