The marketing manager is hypothesis-testing: she might use this data for a while and then realize that adding geographic information would be useful too since a marathon is going to take place in this town. This way, she can figure out which folks and their friends who live in proximity to each other and have purchased running shoes in the past. Adding this new information to the database would require yet another change to the schema. Anytime you decide to explore any additional “relationships,” you need to modify the schema. Changing a schema on a production system is a big deal; it can take several weeks and not something that database admins take lightly. There are better ways of analyzing data without modifying your database, but the point I’m trying to illustrate here is that tables are by design compact; while great for certain things, discovering patterns is not one of those things…

Hence the need and emergence of an alternative data representation format: graphs. Basically, a graph is made up of nodes that are connected to other nodes via an edge. In a graph database, the edge represents the relationship between the data entities represented by the nodes.

[...]

• Relational databases are optimized for a compact representation, and do that very efficiently.
• Graph databases on the other hand, are very flexible when it comes to adding new relationships
• Graph database are further enhanced by facilities like ontologies, inferencing, and more expressive query languages like SPARQL.