Why Graph Databases?

Someone once said, “if graph databases are so great, why aren’t they more popular?” First let’s see how great they are—or at least why we might want to consider them.

A Relational World?

The term “relational database” is kind of a joke. The name comes from the mathematical term relation, which is a set of tuples, or basically a table. So if you have an application consisting of people and movies, then the two relations are Person and Movie. But how are people are movies related to each other? Those are not the relations that the relational model refers to as relations.

When normal people think of relations, they think of relationships between, among other things:

People (how they are related to each other, whether, blood, marriage, friendship, co-working)
Web resources (think hyperlinks)
Delivery destinations (routing)
Tweets (replies, likes, etc.) or Tweeters (followers, etc.)

Writing applications in these domains using relational databases can be done, but you have to fight the model.

But managing richly connected data in a graph database is natural. Graph databases are the real “relational” databases.

Fighting the Relational Model

There are at least two scenarios in which the relational (ahem, tabular-with-foreign-key) model of data is painful: non-uniform data and relationship chains.

Non-Uniform Data

The real world is:

Almost always: messy and irregular
Only sometimes: constrained, uniform, and regular

Relational databases assume the opposite.

TODO: EXAMPLE WITH NULLS IN A COLUMN

TODO: EXAMPLE WITH LOTS OF NULLS (SINGLE TABLE INHERITANCE)

Relationship chains

TODO: EXAMPLE WITH RECOMMENDATIONS: CUSTOMERS WHO BOUGHT THIS ALSO BOUGHT THAT... Tables: Customer, Order, Line Item, Product

TODO: EXAMPLE WITH CHAINS WITHIN THE SAME TABLE, PERHAPS TWEETS WITH PREDECESSORS