Database Reference
In-Depth Information
Why (or why not) graph databases
By now, you should have a good understanding of what graph databases are, and
how they relate to other database management systems and models. Much of the
remainderofthis topic willbedrillingintoquiteabitmoredetailonthespeciics
of Neo4j as an example implementation of such a database management system.
Before that, however, it makes sense to explore why these kinds of databases are
of such interest to modern-day software professionals - developers, architects,
project and product managers, and IT directors alike.
The fact of the matter is that there are a number of typical data problems, and database
system queries are an excellent match for a graph database, and that there are a number
ofothertypesofdataquestionsthatarenotspeciicallydesignedtobeansweredby
such systems. Let's explore these for a bit and determine the characteristics of your
dataset and your query patterns that will determine whether graph databases are
goingtobeagooditornot.
Why use a graph database?
When you are trying to solve a problem that meets any of the following descriptions,
you should probably consider using a graph database such as Neo4j.
Complex queries
Complex queries are the types of questions that you want to ask of your data that
are inherently composed of a number of complex join-style operations. These
operations, as every database administrator knows, are very expensive operations
in relational database systems, because we need to be computing the Cartesian
product of the indices of the tables that we are trying to join. That may be okay for
one or two joins between two or three tables in a relational database management
system, but as you can easily understand, this problem becomes exponentially bigger
with every table join that you add. On smaller datasets, it can become an unsolvable
problem in a relational system, and this is why complex queries become problematic.
Anexampleofsuchacomplexquerywouldbe:indalltherestaurantsinacertain
London neighborhood that serve Indian food, are open on Sundays, and cater for
kids. In relational terms, this would mean joining up data from the
restaurant
table,
the
food type
table, the
Opening hours
table, the
Caters for
table, and the zip-code
table holding the London neighborhoods and then providing an answer. No doubt
there are numerous other examples where you would need to do these types of
complex queries; this is just a hypothetical one.
