For example, I may have a relation in an e-commerce domain as below:
Product producedBy Company
And in another domain, I may have a similar relation:
Pollution producedBy Vehicle
In both cases, 'producedBy' is an intuitive relation name and makes sense. However, the node types in both relations are completely different. In such a case, should I use a different name to represent the two different relations, or it is better to use the the same name as above? If I use different relation names, I may have to create a lot more relation names for similar situations.
Any recommendations on the choice of relation name in such cases?
That being said, if the two types of relationships are used very differently and never overlap, then it would be better to keep them separate.
The reason why, is underneath the covers Neo4J collects Labels in Sets. If you have a union of dissimilar Labels that are actually disjoint, then you have an overly large Set that has to be scanned when picking out Label matches. The smaller the sets, the faster the transversals.
I hope that helpl. (and I'm sure if I'm not exactly right, I'll be corrected!)
I just got my Neo4j modeling certification yesterday.
The Graph Data Modeling for Neo4j online training is really good and even if I was using Neo4j for 2 years I learned a bunch of stuff to be exactly sure about how to model a database.
Short answer : I would need your queries questions, graph schema and the scalability of it to answer properly, it's not that easy, optimising a graph is something.
But roughly by guessing the size and schema of your graph and possible questions related to it, it's OK if these relations are not part of the same graph / database. It's 100% NOT if they are.
Relationships type are really important in query performance to avoid the gather-and-inspect behaviour. Meaning scanning a bunch of connected nodes not related to your query, called wasted hops.
If they are in the same graph, I would suggest something like Pollution EMITTED_BY