Neo4j Training - Graph Data Modeling for Neo4j - Common Graph Structures - Timeline tree

Hi,

On the page Common Graph Structures - Graph Data Modeling for Neo4j I cannot appreciate the efficiency of the direction between the codes Purchase, Day, Month and Year.

Shouldn't the relationship be Purchase -> Day -> Month -> Year, rather than Purchase -> Day <- Month <- Year?

Thanks

Hi @chribonn,

I reckon it's more intuitive when we say Purchase -> Day <- Month <- Year, as Month and Year, will have rolled up values from it's leaf node (i.e Month node would hold all days purchase for mentioned MONTH_OF relationship, similarly Year would hold all 12 months purchase for YEAR_OF). However, i will wait for neo4j team response to validate my understanding here. Thanks

It may depend on the use case ultimately (maybe I'm influenced more by the transactional aspects). But I must admit I can't figure out the reasoning.

Following the tutorial, arrow directions are somewhat confusing for me and, in my opinion contradict earlier sections of the tutorial.

Take, for example, Refactoring and Evolving a Model - Graph Data Modeling for Neo4j section ** Goal: Use labels instead of property values** and the example diagram https://neo4j.com/graphacademy/training-gdm-40/_images/ExtractLabelFromPropertyBefore.png

My reasoning is that User WROTE Project; User CONTRIBUTED_TO Project. The direction of the arrow in the latter case is not correct if we assume that line of through.

I realise that one could also say Project [was] CONTRIBUTED_TO [by] User but, IMO it seems to contradict earlier sections of this tutorial.

Regards

Hi chribonn,

actually as neo4j works with directed graph, that mean it is mandatory to define a direction to the arrow. But it has no "meaning":
(John)-[is_married_with]-(Anna)
might be readable in both direction, but you must defined an arrow direction to it:
(John)-[is_married_with]->(Anna)

It is up to the developper to create a data model that make sense:
(bicycle)<-[has]-(wheel)
is something which might be contraversal for human, but the computer don't care because the computer is not able to extract the meaning of it. So it works anyway.

I also spend hours on this. There is no solution. There is no right or wrong. There is only "something" that "someone" define as the "way it has to be described" in the database. Of course the someone should try to think the standards he/she is setting in order to avoid confusion.

In case of
Purchase -> Day <- Month <- Year
This is not a Month regardless of the given year but really one of the 12 month of the given year.
And day is not 1, 2, ..31 but 2021-08-06 or 2018-02-24. This is a "child_of" the given month (itself 2021-08 an 2018-02)
Therefore, this is a tree and it is common sense to set the direction from root to the leaves.
But another developer would have may be decided the other way.

Year -> Month <- Day would work too. But it is a bad design, because it breaks the possibility to search for pattern over the month:
Match (y:Year{value:2021})-[*2]->(d:Day)
(in order to get all days of 2021) won't be possible.

2 Likes