That's also an option of course. But my guess is that finding all the nodes in a particular labelled set is going to be faster than finding all the nodes that have a link to a particular other node - and it means that in more complex queries we don't have to add an extra graph-traversal hop to restrict the results to products that are associated with a particular campaign.
It seems as if containment hierarchies and labels are well-suited to each other in general. Dominic On Friday, 17 January 2014 12:12:29 UTC+8, Wes Freeman wrote: > > I think maybe you should consider just linking the campaign nodes directly > to the product nodes, rather than using labels for this. > > Wes > > > On Thu, Jan 16, 2014 at 10:00 PM, Dominic Fox <[email protected]<javascript:> > > wrote: > >> Suppose we have a graph which represents a containment hierarchy: >> >> Campaign -> Bundle -> Offer -> Product >> >> A Campaign is a marketing campaign; a bundle is a collection of offers >> within a campaign; a product is an item included within an offer. Each item >> may have multiple parents (so it isn't simply a tree) - for example, the >> same Offer may appear in multiple Bundles, the same Bundle may appear in >> multiple Campaigns. >> >> If we want to find which campaigns a given product is offered in, we can >> traverse the graph upwards towards its "great-grandparents" in the >> hierarchy. But for efficiency, we would like to have that information >> immediately available in the Product node itself - for example: >> >> MATCH c:Campaign --> b:Bundle --> o:Offer --> p:Product >> WITH p, collect(distinct c) AS campaigns >> SET p.campaign_names = [campaign in campaigns | campaign.name] >> >> We then have a short-cut for finding which products are in a particular >> campaign: >> >> MATCH p:Product >> WHERE "my campaign" IN p.campaign_names >> RETURN p.name >> >> This is not yet as efficient as it could be, because campaign_names is an >> array property, so even if we have a schema index - >> >> CREATE :Product(campaign_names) >> >> - the index will not be used when matching on a single element in the >> array, as above, because schema indexes currently only support total >> matches. >> >> We would like to use labels, rather than array properties, to identify >> which campaigns a product is in. This makes sense because the relationship >> between products and campaigns is ultimately one of set-membership. So if >> we wanted the products in both CAMPAIGN_A and CAMPAIGN_B, it would be as >> simple as doing >> >> MATCH p:Product:`CAMPAIGN_A`:`CAMPAIGN_B` >> RETURN p.name >> >> However, there doesn't seem to be a way to set labels dynamically, based >> on property values. In other words, there's no syntax like >> >> MATCH c:Campaign --> b:Bundle --> o:Offer --> p:Product >> WITH p, collect(distinct c) AS campaigns >> FOREACH (campaign in campaigns | SET p:{campaign.name}) >> >> This would be useful to have. Are there any plans to add it to Cypher in >> the future? >> >> Thanks, >> Dominic >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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/groups/opt_out.
