Search code examples
neo4jsocial-networkinggraph-databases

Simple social network design flaw with graph database

I was looking at graph databases and Neo4j. As suggested, I tried to draw a simple social networking graph on white paper and after a few sketches I stucked at some similar points.

At first I designed a social network where "user"s can "like" "post"s.

(u1:User)-[:LIKED]->(p:Post)<-[:POSTED]-(u2:User)

Now I want to notify user2 about the like action and draw this on the white paper.

(u1:User)-[:LIKED]->(p:Post)<-[:POSTED]-(u2:User)
              |                            ^
              |__________[:NOTIFY]_________|

I am not sure if it is clear but I just drew a relationship between a node and another relationship which is not possible for graph databases, at least for Neo4j. So I decided, a Like should be a node instead of a relationship. Then my graph turned into this.

(u1:User)-[:CREATAD]->(l:Like)-[:BELONGS_TO]->(p:Post)<-[:POSTED]-(u2:User)
                          |                                           ^
                          |__________________[:NOTIFY]________________|

Now everything is OK. Then I added Comments feature to the system as a relationship but when notifications involved, again it turned into a node. And same happened when I added "Liking comments" feature, "Likes to Comments" first seemed they are relationships but once again they turned into nodes when notifications involved.

In general, at some point I find myself drawing a relationship between a node and another relationship. My solution to that feels like I am turning entities, which naturally look like relationships, into nodes. And this makes me think of I have some problems with deciding what should be a node and what should be a relationship.

So my question is, does anyone else other than me fall into this "relationship between a node and another relationship" issue and if so how do you solve that?

Solution

  • It all depends on your use-cases, in many cases a simple relationship is good enough but if you want to do more with that entity or fact you turn it into a node, oftentimes it turns out that it is an actually quite important concept in the domain.

    In our data modeling class there is a specific section on this and also in the "Graph Databases" book it is discussed in detail (you can get the free PDF here).

    Sometimes it makes sense to keep the original relationship around for a fast shortcut crossing over that intermediate node if you don't need that detail.