What is the meaning of duplicate relationship between two nodes?

General Newbie Questions
1

When I do multiple times:

MATCH (entity: Entity{ collection_id: 10 })
MATCH (rule: Rule{ collection_id: 10, id: "strength_greater_than_0", column: "strength", operation: "greater_than", value: "0" })
WHERE entity.strength > 0
CREATE (rule)-[r:APPLIES_TO]->(entity);

Then the first time the count done with the query:

MATCH (Rule{ collection_id: 10, id: "strength_greater_than_0", column: "strength", operation: "greater_than", value: "0" })-[r:APPLIES_TO]->(Variant) return count(r);

amounts to: 1758393 whereas a count done after repeating the CREATE query yields: 2344524
indicating that the relationship has been created again. What benefit is there for neo4j to allow duplicate relationships to exist between two the same nodes in the same direction?

2

it is allowable that the same relationship type could exist between the same 2 nodes, as in your case the relationship type is :APPLIES_TO, but a user may want to add properties to the relationship itself. Perhaps :APPLIES_TO has a propery named status which describes if the relationship is active or not

3

This is stating that two relationships of the same type, e.g. APPLIES_TO between two the same nodes could be annotated differently. One could add property status to one relationship without adding it to the other.
But that does not explain the reason why NEO4J accepts two relationships to coexist within the same nodes in the same direction. Annotating a relationship and allowing duplicates of that relationship are two different matters.
Am I overlooking something from your answer?

4

allows it, no different than a RDBMS allowing allowing a row in table to appear 2x's or more and have a foreign key to another single row in another table. Whether or not it makes sense for your application model is up to you

5

Thanks for the analogy. That was helpful to think of some use cases for a duplicate relationship.

An example would be that instead of introducing new nodes each time some event occurs, one could model the occurrence of that event with a separate relationship that although may have the same label, has different properties such as a timestamp of occurrence and level of severity etc.

A very naive example:

(Origin{ip: 1.1.1.1})-[REQUEST {date: ..., duration: ...., status: 404}]->(Company{id: 1})
(Origin{ip: 1.1.1.1})-[REQUEST {date: ..., duration: ...., status: 404}]->(Company{id: 1})
(Origin{ip: 1.1.1.1})-[REQUEST {date: ..., duration: ...., status: 404}]->(Company{id: 1})
(Origin{ip: 1.1.1.1})-[REQUEST {date: ..., duration: ...., status: 404}]->(Company{id: 1})
(Origin{ip: 1.1.1.1})-[REQUEST {date: ..., duration: ...., status: 404}]->(Company{id: 1})

could allow for a throttling mechanism where 5 requests within a certain duration triggers an update to Origin to have its property status set to 'suspicious' or even 'throttled'.
I guess that is what you basically hinted towards in your previous reply but that I failed to understand at the time.

A follow up newbie question here is are those duplicate relationships travelled separately or is NEO4J smart enough to avoid a separate travel between the two same nodes. I am asking in terms of whether such duplicate relationship usage would bring us in super-node territory.

6

see Modeling Airline Flights in Neo4j | Max De Marzi for a modeling example of airline flights and drawbacks of the model you last propose.

We have Node indexes but generally not relatonship indexes. So if you ran

match (n:Origin {ip: 1.1.1.1})-[REQUEST {date: 01/02/2019, duration: 60, status: 404}]->(Company{id: 1}) return n;

if you had an index in :Origin(ip) we would use the index as a means to quick find these nodes but then we would need to traverse every :REQUEST relationship to a :Company node at {id:1} and find only those relationships which had property date: 01/02/2019, duration: 60, status: 404}

7

Is there a CONSTRAINT that doesn't allow multiple relations of the same type between two nodes?

8

no.

Constraints and what is available is described at https://neo4j.com/docs/cypher-manual/current/administration/constraints/