Relations in RavenDB

Just by using a non-relational database your data doesn’t stop to be related. Therefore you must find a way to express a relation even if your database can’t enforce such constraints. What is true for most NoSQL solutions is (for once) also true for RavenDB.

As explained in Designing Documents for RavenDB your documents should be self-containing and use redundancy with care. A good example of this is the sample database with its orders and products. It has enough redundancy to have a full order document that stand on its own, but not too much that you couldn’t change the price of your goods.

Today I will show you how to do the same with your data. You basically have 3 main ways for modelling relations between objects. What works for one relation may not be a good fit for another. You can and should choose for every relation individually what works best.

This post is part of the RavenDB series. You can find the other parts here:

 

Authors and Books

Authors write books and books are written by one or more authors. This n:m relation is great to explain the different possibilities we have to model associations in RavenDB. In my examples I use the book class as my primary object.

This is a valid approach when the application should represent a book collection, but it would be wrong when you want to manage authors. Please keep this in mind when you decide how you want to connect data in your application.

I have these two classes in my application:

 

Embed Objects

The simplest way to model a relation between Book and Author would be to embed the author objects directly inside the book document. All I need to do is add a list of authors to the book class:

To bring both objects together I can add the author to the list:

The result is a document for the book with all the author fields inside:

This is simple but as soon as an author writes more than one book I have to update multiple documents to set his new Twitter handle.

 

Use Object Identifiers

Instead of adding the whole author to the book I could only add the object Id. All I have to do is to change the type of the list from Author to string:

The code to relate the book with the author is nearly the same but the author must be saved independently – otherwise the Id property will be empty:

The resulting document doesn’t duplicate the author’s values, but to know who wrote the book I need another document:

 

Useful Duplication

Somewhere between the duplication of all the fields and just having the Id is the document I want to work with. The name of the author most likely doesn’t change often and it would help me a lot when I’m looking at the book object. For adding just a few selected fields we need a helper object:

The code I have to write is not much different than in the first example:

The JSON document has now all I need to know about the book and only 1 document needs to be updated when the author joins Twitter:

 

Next

With these 3 ways to relate documents you know the basics and can combine them as it fits your application. In the next post you will see how easy it is to use paging in RavenDB.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.