[As community content, this post reflects the views and opinions of the particular author and does not necessarily reflect the official stance of Neo4j.]

Have you ever wondered: What exactly are graphs useful for? How do they influence the world around us?
Read This Intro to Graph Databases from a Developer’s Perspective

Probably not. Not because you didn’t want to or can’t, but because we are so knee-deep in the world of graph databases that we take it for granted.

My post here introduces you to graph-based databases, particularly Neo4j. Graph databases are one of the major outcomes of the NoSQL revolution, which took the world of data persistence by storm by providing a whole bunch of different options of data storage, completely different from the time-tested method of information storage: the relational database management (or RDBMS).

We’ll have a look at some scenarios comparing the query development complexity of SQL and Cypher, the language used by Neo4j, using the classic friends-of-friends example. We’ll also analyze when to use graphical, document-oriented, key-value-pair-based or column-family-based storage options over relational database management, and vice versa.

If you’re already familiar with graph databases in general, then you also need to learn about Neo4j in particular.

These days, Neo4j is a buzzword. Everyone (well, a hyperbole, but still accurate) wants to be a part of it and everyone wants to learn it. So, how and where do you start?

In this second post, I make my best attempt at answering those questions, so that you feel at ease understanding the basics of Neo4j. I accomplished this with the help of a very-nerdy graph database scenario; something you might like, enjoy, and learn from – all at the same time!

We start with how to install and start using a Neo4j instance, how to navigate its console and how to use it for querying data. Then we move on with example queries of how the different parts of the Cypher query language come together to make understanding various real world situations easier.

These examples outline the areas where the data would be harder to represent and extract using a relational database (both in terms of the time taken and the complexity of querying), but where a graph database doesn’t sweat about it at all.

Hope you enjoy reading and learning through it, as much as I absolutely loved writing it! Let me know if you liked it!


For more from Sabhya Kaushal, follow him on Twitter.


Want to learn more about graph databases? Click below to get your free copy of O’Reilly’s Graph Databases and get started building your own graph database application today.

Get My Free Copy

 

Keywords:  


About the Author

Sabhya Kaushal, Community Contributor

Sabhya Kaushal Image

Sabhya Kaushal is a community contributor to the Neo4j blog.

With Java being his soulmate, and geekery the second nature, Sabhya enjoys long walks in the wild and playing table tennis, even though his four years of practice have yielded practically nothing. Learning new things and becoming an expert programming polyglot is his dream. He thinks he’ll look considerably better with a goatee.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

Upcoming Event

 


Have a Graph Question?

Stack Overflow
Slack
Contact Us

Share your Graph Story?

Email us: content@neo4j.com