Database Reference
In-Depth Information
Design for query-ability
Like with any database management system, but perhaps even more so for a graph
database management system such as Neo4j, your queries will drive your model.
What we mean with this is that, exactly like it was with any type of database that
you may have used in the past or would still be using today, you will need to make
speciicdesigndecisionsbasedonspeciictrade-offs.Therefore,itfollowsthatthere
is no
one perfect way to model
in a graph database such as Neo4j. It will all depend on
the questions that you want to ask of the data, and this will drive your design and
your model.
Therefore, my number one and undoubtedly the most important best practice for
graph database modeling is to start with your user story. What does the user of the
systemthatyouaredesigningwanttoknowfromthedata?Anexampleofsucha
story could be something like this:
"as an employee, I want to know who in the company I work for has similar skills
to me so that we can exchange knowledge"
This excerpt tells a little bit about the entities that I need to include in the model
and the connections that should exist between these entities. Different domain
descriptions would probably add similar or different entities and similar or
different connections and will then gradually complete your model.
Align relationships with use cases
One of the ways that you can model for
query-ability
and let your queries drive
your model is by using the different relationship types that you can have between
nodes for different use cases. Many great graph database models use multiple
relationships between two of the same nodes for different use case scenarios.
One of the reasons why this recommended best practice is actually applicable and
of real use in practical development efforts is that the specialization tax, which is the
price that you, as a developer, pay (mostly in terms of added model complexity) for
introducingaspeciicrelationshipbetweentwonodesforaspeciicusecase—for
introducing this additional relationship is in fact so low. There are no additional
tablesorschemastobecreated,andtobeevenmorespeciic,therearenoadditional
joins to be computed. All that happens is that the graph traversals will use different
paths to establish their course across the network stored in the database.
