Building models in NOSQL

Question

We are trying NOSQL Document database (ravenDB) and we are asking ourselves some questions. This is our models :

public class User
{   
    public Guid Id {get;set}
    public string Name {get;set;}   
}

public class Video
{
    public Guid Id {get;set;}
    public string Nom {get;set;}    
    public DateTime PublishDate {get;set;}
    public User Publisher {get;set;}
    public Uri Adress {get;set;}
}

By default, a video can not be read by anyone. You can add the rights to see the video at a user or a group of user. You can recommand a video to a user or a group of user(the rights to see the video is added automatically).

What is the best way to design the models for a NOSQL Document database considering the following use case :

• A user is publishing a video he can choose which group(s)/user(s) can see the video and recommend the video to some user(s)/group(s)
• A user withdraw the rights to see the video at some user(s)/group(s)
• Get the last N videos that a user has been authorized to read
• Get the last N videos that have been recommended for a user

We are considering the following :

• Add 2 List for each model (VideosReadable, VideosRecommended and UsersAllowedToRead, UserRecommended) where the first list contains all the elements of the second
• Add a list of Tuple for each model (ListTuple<User, bool>> and List<Tuple<Video, bool>>), the bool indicates that if it is recommended.
• Add a Document UserVideoLink

Which one would be the easiest model for querying ? Is there other better alternatives?

Answer 1

It all comes down to quantities. How many potential users total? How many potential videos total? How many recommendations and assignments? How often will the data change? There is no one best answer.

You may find, for example, that if you have a lot of everything that you are better off creating separate documents to model the active bits, such as a separate class and document to model a Recommendation and another to model an Assignment.

Then again, if one user only has access to a handful of videos, you may find it easier to embed a list of VideoIDs in each user, or a list of Video objects which may or may not be the full video document or just a be a small denormalized piece of data.

You'll have to experiment and decide what works best for you.

However, I'd stay away from using Tuple. They get a bit messy. You'd do better with a class of your own creation for that purpose.

I would also avoid a name like UserVideoLink - that doesn't fit the DDD ideas very well. Think of it more as what you are modeling instead, such as a Recommendation.

Some of this may sound like very relational-database thinking, but it does have a place in document databases also. Just because a document can have structure doesn't mean that everything has to go in a single document. Try to model your domain first using DDD concepts. Then everything you've identified as an "Aggregate Root" entity, and all child entities thereof, (usually) belong in a single document.