Hi Benny, In your examples, which seems to have an very finite numbers of relationships types, i would go for adding relationship vs properties. Thus the traversal can be done cheap rather than involve properties that would be needed in the look-up. This is the best design performance wise. But of course if your domain-model involves nodes that becomes dense with millions of outgoing relationship and the number of relationship cant so easily be forseen and you want query from that node i would think adding a properties make sense.
Here is actually a good blog post on the topic: http://graphaware.com/neo4j/2013/10/24/neo4j-qualifying-relationships.html It is very hard without further insight to say exactly how to model your domain. And dont fortget that you can also limit the serach result by a type as well, as in (x)-[r]->(y) where type(r)="IS_DAUGHETR_OF" Mabey you could test some CSV data of a known domain, import it and try some models and find out ? I would be happy to read such a report. Den onsdagen den 16:e april 2014 kl. 14:09:48 UTC+2 skrev Benny Kneissl: > > Hi, > > as far as I know the smartest way to store hierarchies for node entities > is to use the new label feature. Lets's suppose an entity is of type B > where B is a subclass of A. Then the node is labeled by both A and B, right? > > But what about hierarchies for relationships? Should several relationships > be stored between two entities to model hierarchies for relationships? > Should the type of the relationship differ or is it more meaningful to have > the same type but different properties? > > A possible example is that "isDaughterOf", "isSonOf" are subtypes of > "isChildOf" when modeling a family tree. Or from biology when having a > BiochemicalReaction you might want to model "isParticipantOf", "isEductOf", > "isProductOf". > > In this simple hierarchy I think it is sufficient when asking for all > children to traverse both relationship types, but the hierarchy might > become more complex and then, it is likely that you forget one relationship > type in Cypher ( (x)-[r:IS_DAUGHTER_OF | IS_SON_OF]->(y) ). If you use > only one type ((x)-[r:IS_CHILD_OF]->(y)) you have to add a property > daughter / son to ask only for daughter/son. So what is a good way > (performance, complexity in formulating a query) to do it in Neo4j? Adding > more relationships, or adding more properties? > > Currently I don't know what are the advantages for the different > approaches, in particular, with respect to formulate queries afterwards. > > Thank you for some ideas you have in mind, > > Benny > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
