CODEWITHSUNDEEP
nosqldomain-driven-designravendb
Pak
Pak

Reputation: 2766

Building models in NOSQL

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 :

We are considering the following :

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

Upvotes: 1

Views: 440

Answers (1)

Matt Johnson-Pint
Matt Johnson-Pint

Reputation: 241525

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.

Upvotes: 1

Related Questions