Database Reference
In-Depth Information
Whichoneofthesemodelsisright?Iwouldsaybothandneither.Thereal
fundamental thing here is that we should be looking at our queries to determine
which version is appropriate. In general, I would argue that:
• If we don't need to evaluate the alcohol percentage during the course of a
graph traversal, we are probably better off keeping it as a property of the
end node of the traversal. After all, we keep our model a bit simpler when
doing this, and everyone appreciates simplicity.
• If we need to evaluate the alcohol percentage of a particular (set of) beer
brands during the course of our graph traversal, then splitting it off into its
own node category is probably a good idea. Traversing through a node is
often easier and faster than evaluating properties for each and every path.
As we will see in the next paragraph, many people actually take this approach even
a step further by working with in-graph indexes.
Use in-graph indexes when appropriate
Taking the granulate pattern even further and knowing that most indexing
technologiesactuallyusegraphs/treesunderthehoodanyway,wecanapplythis
pattern to create natural indexes for our data models, inside the graph. This can be
veryusefulforspeciictypesofquerypatterns:rangequeries,timeseries,proximity
searches, and so on.
Looking at our previous little beer model, the alcohol percentages could be a prime
candidate for these in-graph indexes. The idea here is that we connect all of the alcohol
percentages to one another and create a linked list of alcohol percentages that we could
followupwardordownward,forexample,toindbeerbrandswithsimilaralcohol
percentages within a certain range. The model is displayed in the following diagram:
An in-graph index on alcohol percentages
