Hi Lundin,
I found now an real-world example and maybe you can comment this. In this gene-disease association ontology you have to connect nodes representing genes with nodes representing diseases by their association type. Let's suppose gene A has a GeneticVariationAssociation to disease B, then I have to add 4 relationships (GeneticVariationAssociation, BiomarkerAssociation, GeneDiseaseAssociation, Association) between A and B. Is it recommended to do it this way or are there smarter possibilities? <https://lh6.googleusercontent.com/-bPKb2sdcb4E/U8OXnr1U8eI/AAAAAAAAACQ/8P0IaychxT0/s1600/DisGeNET.png> On Saturday, April 19, 2014 6:18:49 PM UTC+2, Lundin wrote: > > 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.
