Returning to Nature?

We imitate nature. period

It has been going around for trizillions of years that someone actually found time to write a paper about it. Cameras, imitate the eyes, airplanes, imitate the birds, submarines, does the fishes and so on and on.. What about storing relations between objects? Assume, a person is related to another person. Storing it in a fully normalized database would look like this.

Recon it’s self explaining.

This’s our good ‘ol Relational DB. Fast and memory efficient. Do note that i would have put glittering lights or even a disco ball over the memory efficient tag. Storing so much data and using so little memory was a killer idea in those days. But not any more. read this..

Memory is cheap these days and it’s time we moved out of relational databases. Let’s see how nature handles a simple relationship, like the one in the above example… as a Graph.

Two entities (in this case, two persons), a father and a son. They have an invisible link between them. Direct the link from father to son, it’s a ‘father-of’ link. This is where a Graph Database comes into picture.

What’s a Graph db?

A graph db has ideally 3 pillars.

1. The nodes
2. The relationships
3. The properties

The relationship connects nodes and the properties add extra values to the nodes and relationships. Let’s see a neat example

I grew up seeing Matrix and it could not be simpler than this. The blue circles are Nodes and the bold directed lines are relationships.

You can see the properties of relationships and nodes in grey squares.

A graph database uses nodes, relationships between nodes and key-value properties instead of tables to represent information. This model is typically substantially faster for associative data sets and uses a schema-less, bottoms-up model that is ideal for capturing ad-hoc and rapidly changing data.

And if you are looking for an entry point into the graph db universe, it’s here

There are lots of resources available for Graphs online and here’s the article that got my attention..