Database Reference
In-Depth Information
When we execute this query, it takes quite a bit of time, as we need to run through
all nodes and relationships of the tree to get what we want. With a tree of 2.1 million
nodes and relationships, this took about 47 seconds on my laptop. Look at the result
shown in the following screenshot:
Calculating the price based on a full sweep of the hierarchy
Now, anyone who has ever done a similar operation at similar scale in a relational
system knows that this is actually a really impressive result. However, we think
we can do better by optimizing our hierarchy management strategy and using
intermediate pricing information in our queries. If we want to perform impact
simulation—the subject of this section of the topic—we really want this price
calculation to be super fast. So, let's look at that now.
Calculating the price based on intermediate pricing
The strategy optimization that we will be using in this example will be to use
intermediate pricing at every level of the tree. By doing so, we will enable our price
calculation to span a much smaller part of the graph, that is, only the part of the graph
thatchanges—thenode/relationshipthatchangesandeverything"above"itinthe
hierarchy—will need to be traversed when performing our impact simulations.
To do so, we need to add that intermediate pricing information to the hierarchy.
Currently, only the lowest cost component level has pricing information. Also, we
need to calculate that information for all levels of the hierarchy. We use a query
similar to the following one to do so:
match (n5:COST)<-[r5]-(n6:COST_COMPONENT)
with n5, sum(r5.quantity*n6.price) as Sum
set n5.price=Sum;
Essentially, what we do is we look at one level of the hierarchy, traverse upwards
to the level above, and set the price of the upper level equal to the sum of all
products of the price of the lower level and multiplied by the quantity of the
relationship that connects it to the upper level.
