cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! Site migration is underway. Phase 2: migrate recent content

Downsides of using the same relationship in different contexts?

davidmakovoz
Node Clone

I have faced this situation many times before and finally decided to ask the question here.
Often you have a relationship name that fits in different contexts. E.g. IS_PART_OF can describe relationships between Employees and the Group they are part of and Material and Material Group the Material is part of, and there are often other cases within the same model. I would first use a synonym, instead of IS_PART_OF use BELONGS_TO, but then I would run out of synonyms and ask myself, what's wrong with using the same IS_PART_OF in different contexts?

3 REPLIES 3

kathryn_moore
Node Clone

One reason is query performance. When giving the relationship in a query you want that to limit the graph as much as possible, so that you are traversing the smallest possible portion of the graph. The more specific the labels/relationships are the faster the query will be.

That's what I was thinking, but then I asked myself, usually a query would be:
match (e:Employee)-[:IS_PART_OF]->(g:Group)
Cypher would start with Employee nodes and then follow the IS_PART_OF edges. What does it matter if there are also IS_PART_OF edges connecting (:Material) and (:MaterialGroup) nodes?
The only time it would affect performance if I do something like:
match (e)-[:IS_PART_OF]->(g)
without specifying the node labels (I don't know why I would do that, but that's another story).
Or am I confused and it's not how cypher works?

If you always specify the nodes then it would follow from the node, but you would have multiple IS_PART_OF relationships in your schema and code that have different meanings, which would make the code harder to read/maintain.
To avoid ambiguity I would use something like IS_PART_OF_GROUP, MATERIAL_IS_PART_OF.