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:
- Part 1: Introducing RavenDB: NoSQL for .Net
- Part 2: Getting RavenDB Up & Running
- Part 3: CRUD-Operations in RavenDB (.Net Client API)
- Part 4: CRUD-Operations in RavenDB (HTTP API)
- Part 5: Designing Documents for RavenDB
- Part 6: Map/Reduce: A Simple Explanation
- Part 7: Indexes in RavenDB
- Part 8: Set Based Operations in RavenDB
- Part 9: Relations in RavenDB
- Part 10: Paging in RavenDB
- Part 11: Evolving Documents in RavenDB
- Part 12: RavenDB 3: The New Management Studio
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:
public class Book
{
public string Id { get; set; }
public string Title { get; set; }
public string ISBN { get; set; }
public int Pages { get; set; }
}
public class Author
{
public string Id { get; set; }
public string LastName { get; set; }
public string FirstName { get; set; }
public string Twitter { get; set; }
public string Email { get; set; }
}
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:
public class Book
{
public string Id { get; set; }
public string Title { get; set; }
public string ISBN { get; set; }
public int Pages { get; set; }
public List<Author> Authors = new List<Author>(); // *** NEW ***
}
To bring both objects together I can add the author to the list:
using (var documentStore = new DocumentStore
{
Url = "http://localhost:8080",
DefaultDatabase = "Demo"
}.Initialize())
using (var session = documentStore.OpenSession())
{
var book = new Book{Title = "RavenDB and Related Documents"};
var author = new Author{LastName = "Graber", FirstName = "Johnny", Email = "JG@..."};
book.Authors.Add(author);
session.Store(book);
session.SaveChanges();
}
The result is a document for the book with all the author fields inside:
{
"Authors": [
{
"Id": null,
"LastName": "Graber",
"FirstName": "Johnny",
"Twitter": null,
"Email": "JG@..."
}
],
"Title": "RavenDB and Related Documents",
"ISBN": null,
"Pages": 0
}
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:
public class Book
{
public string Id { get; set; }
public string Title { get; set; }
public string ISBN { get; set; }
public int Pages { get; set; }
public List<string> Authors = new List<string>(); // *** NEW ***
}
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:
using (var session = documentStore.OpenSession())
{
var book = new Book { Title = "RavenDB and Related Documents" };
var author = new Author { LastName = "Graber", FirstName = "Johnny", Email = "JG@..." };
session.Store(author); // *** NEW ***
book.Authors.Add(author.Id); // *** NEW ***
session.Store(book);
session.SaveChanges();
}
The resulting document doesn’t duplicate the author’s values, but to know who wrote the book I need another document:
//books/65:
{
"Authors": [
"authors/65"
],
"Title": "RavenDB and Related Documents",
"ISBN": null,
"Pages": 0
}
//authors/65:
{
"LastName": "Graber",
"FirstName": "Johnny",
"Twitter": null,
"Email": "JG@..."
}
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:
public class Book
{
public string Id { get; set; }
public string Title { get; set; }
public string ISBN { get; set; }
public int Pages { get; set; }
public List<AuthorInfo> Authors = new List<AuthorInfo>(); // *** NEW ***
}
public class AuthorInfo
{
public string Id { get; set; }
public string LastName { get; set; }
public string FirstName { get; set; }
public AuthorInfo(Author author)
{
Id = author.Id;
LastName = author.LastName;
FirstName = author.FirstName;
}
}
The code I have to write is not much different than in the first example:
using (var session = documentStore.OpenSession())
{
var book = new Book { Title = "RavenDB and Related Documents" };
var author = new Author { LastName = "Graber", FirstName = "Johnny", Email = "JG@..." };
session.Store(author);
book.Authors.Add(new AuthorInfo(author)); // *** NEW ***
session.Store(book);
session.SaveChanges();
}
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:
//books/97:
{
"Authors": [
{
"Id": "authors/97",
"LastName": "Graber",
"FirstName": "Johnny"
}
],
"Title": "RavenDB and Related Documents",
"ISBN": null,
"Pages": 0
}
//authors/97:
{
"LastName": "Graber",
"FirstName": "Johnny",
"Twitter": null,
"Email": "JG@..."
}
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.
The post Relations in RavenDB appeared first on Improve & Repeat.