views:

224

answers:

2

I have been looking into document databases, specifically RavenDb, and all the examples are clear and understandable. I just can't find any example where we do not know beforehand how many levels a given structure has. As an example how would you persist a family tree given the following class:

public class Person{
     public string Name {get;set;} 

     public Person Parent {get;set;}
     public Person[] Children {get;set;}
}

In most examples I have seen we search for the aggregate root and make into a document. It is just not so obvious here what the aggregate root and boundary is.

+1  A: 

I guess for RavenDb, you'd have to keep the Ids in your object:

public class Person {
    public string Name { get; set; }
    public string ParentId { get; set; }
    public string[] ChildrenIds { get; set; }
}

Check this page, especially at the bottom, for more info: http://ravendb.net/documentation/docs-document-design

Peter
Right, this was also my first inclination. But as it also says, this in some sense goes against the basic ideas behind document databases. Querying data modelled this way could be really slow compared to more aggregated documents. What I am looking for is some less "obvious" strategies.
Rune Hammerskov
I posted this in the RavenDb Google Group (http://groups.google.com/group/ravendb/browse_thread/thread/8a75de45916a8593). I expect you should get an answer shortly.
Peter
I guess it partly depends on what you consider your "aggregate root" to be. For instance is the common operation pulling out a particular person and all their descendants down to a certain level, i.e. 3 generations? If so you could store that as your document.The general principle of RavenDB is that writes are expensive, but reads are cheap. So a document should stand on it's own.
Matt Warren
+1  A: 

Ayende has just posted a blog post that answers this.

Matt Warren
Just saw it in RSS-feed :) The solution of denormalizing the data requires you to know precisely what you need everywhere in your UI, but I guess for most scenarios that is the technique I would use.
Rune Hammerskov
Yeah good point, but I think that understanding that part is the main different of RavenBD v RDMS. Plus you can use indexes to sit on top of the documents to pull out other "views".
Matt Warren
To make any updates easier you can use set-based operations (see http://groups.google.com/group/ravendb/browse_thread/thread/d898694f321586ea) so you can use an index to update documents directly, rather than pulling them from the server, modifyung and posting them back.Also you can PATCH documents, see http://www.ravendb.net/documentation/docs-http-api-patch.
Matt Warren