Databases Reference
In-Depth Information
Figure 4-7. A doubly linked list representing a time-ordered series of events
Versioning
A versioned graph enables us to recover the state of the graph at a particular point in
time. Most graph databases don't support versioning as a first-class concept: it is pos‐
sible, however, to create a versioning scheme inside the graph model whereby nodes
and relationships are timestamped and archived whenever they are modified.
2
The
downside of such versioning schemes is that they leak into any queries written against
the graph, adding a layer of complexity to even the simplest query.
Iterative and Incremental Development
We develop the data model feature by feature, user story by user story. This will ensure
we identify the relationships our application will use to query the graph. A data model
that is developed in line with the iterative and incremental delivery of application fea‐
tures will look quite different from one drawn up using a data model-first approach,
but it will be the correct model, motivated throughout by specific needs, and the ques‐
tions that arise in conjunction with those needs.
Graph databases provide for the smooth evolution of our data model. Migrations and
denormalization are rarely an issue. New facts and new compositions become new nodes
and relationships, while optimizing for performance-critical access patterns typically
involves introducing a direct relationship between two nodes that would otherwise be
connected only by way of intermediaries. Unlike the optimization strategies we employ
in the relational world, which typically involve denormalizing and thereby compro‐
mising a high-fidelity model, this is not an either/or issue: either the detailed, highly
normalized structure, or the high performance compromise. With the graph we retain
the original high-fidelity graph structure, while at the same time enriching it with new
elements that cater to new needs.
We will quickly see how different relationships can sit side-by-side with one another,
catering to different needs without distorting the model in favor of any one particular
need. Addresses help illustrate the point here. Imagine, for example, that we are devel‐
oping a retail application. While developing a fulfillment story, we add the ability to
2. See, for example,
https://github.com/dmontag/neo4j-versioning
, which uses Neo4j's transaction life cycle to
create versioned copies of nodes and relationships.
