Question

Given a simple example as follows, I’d like some guidance on whether to store as a single document vs multiple documents.

class User
{
    public string Id;
    public string UserName;
    public List<Post> Posts;
}

class Post
{
    public string Id;
    public string Content;
}

Once the data is stored, there are times when I will want all the posts for a given user. Sometimes I might want posts across multiple users that meet a particular criteria.

Should I store each User as a document (with Posts embedded), or does it make more sense to store Users and Posts as seperate documents, and have some sort of ID in my post to link it back to a User?

Now, what if each user belonged to an Organization (there will be hundreds of organizations in my application)?

class Organization
{
      public string Id;
      public List<User> users;
}

Should I then stay with the single document approach? In this case I would store one giant document for each organization, which will contain embedded users, which in turn contain embedded posts?

Answer 1

You should keep them as separate documents. User, Organization, and Post are great examples of aggregate entities, and in Raven, each aggregate is usually its own document.

Only entities which are not aggregates should be nested in the same document. For example, in Post you might have a List<Comment>. Comment and Post are both entities, but only Post is an aggregate.

You should instead model them with references:

public class User
{
    public string Id { get; set; }
    public string Name { get; set; }
    public List<string> PostIds { get; set; }
}

public class Post
{
    public string Id { get; set; }
    public string Content { get; set; }
}

public class Organization
{
    public string Id { get; set; }
    public List<string> UserIds { get; set; }
}

Optionally, you can denormalize some of the data into your references where appropriate:

public class UserRef
{
    public string Id { get; set; }
    public string Name { get; set; }
}

public class Organization
{
    public string Id { get; set; }
    public List<UserRef> Users { get; set; }
}

Denormalizing the user’s name into the organization document has the benefit of not needing to fetch each user document when displaying the organization. However, it has the drawback of having to update the organization document any time a user’s name is changed. You should weigh the pros and cons of this each time you consider a relationship. There is no one right answer for all cases.

Also, you should be considering how data will be really used. In practice, you will probably find that your Organization class may not need a user list at all. Instead, you could put a string OrganizationId property on the User class. That would be easier to maintain, and if you wanted a list of users in an organization, you could query for that information using an index.

You should read more in the raven documentation on Document Structure Design and Handling Document Relationships.