If my data model is based on one particular hierarchy being right, then it will not work very well for all the alternative views of the world. It will work brilliantly for some use cases and not at all well for others.
Graph databases solve this problem by letting you create a network of objects and relationships. Data can be extracted from a graph as if it were a hierarchy by following certain relationships but it doesn’t have to be stored this way. That means you can model all the different hierarchies at the same time. It’s a bit like Scrabble – the hierarchies intersect each other
| G | R | A | P | H | |||||||
| I | |||||||||||
| E | |||||||||||
| R | |||||||||||
| D | A | T | A | B | A | S | E | ||||
| R | |||||||||||
| C | |||||||||||
| T | E | C | H | N | O | L | O | G | Y | ||
| Y |
Lets take a look at a quick example. Here’s my simple model from the film “Finding Nemo”
Using this model we could extract the following hierarchies:
Fish
– Marlin
– Nemo
– Dory
Marlin
– Nemo
Great Barrier Reef
– Fish
– Coral
The great thing about this is that I can add objects and relationships over time as I discover them. Things I have built based on the starting structure will still work, but now more advanced functions can be made.
However, a graph alone will not solve all of the challenges. What if I want to simultaneously represent the following hierarchies:
FISH and
– Marlin
– Nemo
– Dory
FISH
– Clown Fish
– Marlin
– Nemo
– Blue Tang
– Dory
This is where you also need a Class Library and a pragmatic approach to objects and properties which I’ll talk about in the subsequent blogs.
