I'm new to neo4j and I thought that "label" was the same as a "node type" such as a student node, teacher node, etc. Then I came accross this document:
"create-create-a-node-with-multiple-labels"
I have some generic operations that need to do specific things based on the node type, and I thought I could use the "label" property for this, but since a node can have multiple labels, I need some other way to identify what type of node it is.
What is a sure way to identify exactly what type of node it is?
You don’t have to use multiple labels if your domain model doesn’t benefit from them.
You should not be limited in performing your generic operations because on the knowledge that a node can have multiple labels. Do you have an example of one of your generic operations that now concerns you?
I'm just wondering why you would have multiple labels if a label defines the node type. A dog is not a cat, therefore a node should be either a dog or a cat.
Or are label more like tags or indexes as a way to categorize nodes? it seems there should a property on the node that declares what node type it is.
This is my perspective coming from the RDB world and working with TigerGraph which has strongly typed schemas.
Maybe look at it from this perspective:
A cat is not a dog - true - but a cat is an animal and so is a dog (and an elephant and a mouse and ...). So now if you want to fetch all animal nodes, it is much easier if all animals have two labels (the actual animal type they are plus the "Animal" label):
MATCH (a:Animal) RETURN a
instead of
MATCH (a:Dog|Cat|Elephant|Mouse|...) RETURN a
And maybe you want to query for all mammals (no insects, reptiles,...). Then it would be good to have a third label on all nodes ...
This answer caught my attention. Wouldn't it be better to express this through the "is-a" relationship between the animal and the elephant instead of adding several labels? and Why if no?
You could end up creating super nodes with your approach. I tend to look at labels as a means of classifying entities and relationships as a means of relating entities.
I see two purposes for having multiple labels. The first, as described by @mansour.mh.ali, is to model a hierarchical classification system. Having multiple labels, representing each level of the entity's classification, makes it very easy to find all nodes at any level or filter nodes at any level. The cypher is simple. In contrast, if you modeled this with a 'is-a' relationship, you would need to always have some constraint in your queries to filter based on a relationship to the classification node. In addition to more complex cypher, the performance would potentially be worse since at runtime every 'is-a' relationship would need to be navigated to determine if the node on the other end is the correct classification node.
The second use case of using multiple labels would be when you want to classify entities with multiple unrelated classifications. It would not make sense to use properties for all but one main label, as not every node of the main label type may have values for these properties, as they may not have those classifications. Having multiple labels makes if very quick and easy to find any group of nodes based on any classification. If using a property instead, you would have many nodes with null property values, plus how would you define an index since an index is based on a label value and a property.
I have used this in my application where I have a hierarchical classification model for my entities. It works very well and the cypher is very straightforward.
Another reason for multiple labels can be for "hiding" data, or as a way to fine-grain access control.
Maybe you have a database in which you analyze multiple customers' data. In this case you would probably construct the database in which nodes have a single label.
But now a customer wants access to their data. You could simply add a label to all nodes pertaining to that customer as :CustomerB. In the roles, CustomerB can only MATCH on their nodes while "hiding" the data that is not "their's" from being seen.
Add another CustomerC, their labels :CusotmerC, and CustomerC can only MATCH on their nodes, or DENY on other nodes.
Where as you, the owner of the database, can MATCH on all nodes.