Graphs in RavenDB: Graph Modeling vs. Document Modeling

One of the most important design decisions we made with RavenDB is not forcing users to explicitly create edges between documents. Instead, the edges are actually just normal properties on the documents and can be used as-is. This means that pretty much any existing RavenDB database can immediately start using graph operations, and you don’t need to do anything.

The image below shows an order, using the RavenDB’s sample Northwind dataset. The highlighted portions mark the edges from this document. You can use these to traverse the graph by hopping from document to document.

For example, using:

This is easy to do, migrates well (zero cost to do so, yeah!) and usually matches nicely with what you already have. It does lead to an interesting observation. Typically, in a graph DB, you’ll model everything as a graph. But with RavenDB, you don’t need to do that.

In particular, let’s take a look at the Neo4J’s rendition of Northwind:

As you can see, everything is modeled as a node/edge. This is the only thing you could model it as. With RavenDB, you would typically use a domain driven model. In this case, it means that a value object, like an OrderLIne, will not have its own concrete existence. Either as a node or an edge. Instead, it will be embedded inside its root aggregate (the order).

Note that this is actually quite interesting because it means that we need to be able to provide the ability to query on complex edges, such as the order lines. Here is how works:

This will give us all the discount products sold in London as well as their discount rate.

Note that in here, unlike previous queries, we use a named alias for the edge. In this case, it gives us the ability to access its properties and project the line’s Discount property to the user. This means that you can have a domain model with strong cohesion and locality, following the domain-driven design principles while still being able to run arbitrary graph queries on it. Combining this with the ability to pull data from indexes (including map/reduce) ones, you have a lot of things that you can do that used to be very hard but now are easy.