Effectively evolving with graph schema design
When planning a schema in the previous chapters, we assumed that our graph data model would not change. In practice, this is rarely the case. Data requirements can change regularly with the needs of a solution or business, and it is important to consider this in advance. We saw in the last section that it is often more simple to change the schema of a graph than the structure of a relational database.
On the other hand, when a graph database becomes a key part of the tech stack that underpins a valuable system, we would not want to allow drastic shifts in structure and schema, especially those that may disrupt a live service. We have to strike a balance between taking advantage of the mutable structure and schema of a graph database and setting sensible constraints that ensure data is as expected.
For the rest of the chapter, let’s consider a new example, using data from Twitter. Twitter, like many other social media platforms...
