Let's look at how we are going to model our data for this application.
The most difficult part when it comes to building applications as a Fullstack developer or as a back
end developer is how the data is going to be modular.
That is based on my experience.
So let's have a look at the logic behind the data flow.
We are going to build a block application.
So for block application, first step is we need to ask ourselves what are the users, who is going
to use our application and what kind of data that we need.
So let's look at the data flow.
First one is we need users to use the application and for users we're going to have two types or three
types based on your business logic.
One is we can have the admin and then the super admin or any normal user, but for our case we are going
to have two categories of users.
One is authenticated user and then normal user.
When we say authenticated, meaning that a user who has logged in and then the person can create and
then delete a post.
But for a normal user, the person can only view the post.
So the next entity or data that we need to handle is what we call post, because the entire logic about
application is about creating posts.
The next concept is what we call comment because a user can comment on your post.
So we need to have a separate entity or data for comment.
And lastly, we are going to have what is called categories.
These entities is what we call model and mongoose.
So let's say how these models or entities or data are related.
And this is what we call database relationship, meaning how comment is being related to post and how
post is being related to categories, users and comment.
And for Mongoose, we have different types of database relationship.
One is called 1 to 1 relationship, one to many or many to many relationships.
So let's see how these models are going to relate to each other.
First step is let's focus on the users and then the post.
Is it going to be 1 to 1 or one to many or many to many?
In this case, it's going to be one to many relationships, meaning that a user can create many posts.
So if a user view my profile or if I view my profile, I'll be able to see all the posts that I have
created.
The next one going to be the users and then the comment.
Again, a user can create many comments.
So in this case it's going to be one to many relationships.
A user can create many comments, but one comment belongs to a single user.
You can see that this one represents this user and then the red represents this one as well.
So this show is that a comment belongs to a single user and for post and then the user is like I said,
is going to be one to many relationships.
So if I view a single post or be able to see a single user who created that post, I won't be able to
see two or more users who has created a single post.
The next one going to be the users and category for this one to a user can create many categories,
but one category belongs to a single user.
So this is what we call one to many relationship.
So let's look at the comments and posts.
What kind of relationship are you going to use?
Definitely is going to be one to many relationships, meaning that a single post can have many comments,
but one comment belongs to a single post.
So what about post?
And then the category is going to be 1 to 1 relationship, or it can be one to many relationships,
meaning that a post can belongs to two or more categories, but ideally a post belongs to a single category.
For this one, it's up to you.
If you want a post to belong to two or more categories.
So this is the flow.
This is the relationship that we are going to use.
Next is let's talk about how we are going to say the document into the model, for example, users and
posts.
For this one too, we have ways of doing it.
When it comes to MongoDB, one is called using the embedded way, meaning that we are going to save
the entire post into the user's field and this is what we call embedded, meaning we are using the entire
post into the arrays of user field and we have the nest type and that is what you call by referencing
meaning that instead of using the entire object, we are going to use only the idea of the post and
save it into the user's field.
And this is the recommended way of doing it that is using the reference way.
Before we continue for our purpose, we are not going to create a separate model for categories, but
instead we are going to create a field and then pass in the accepted categories.
Well, as we proceed, all this concept will be clear to you.
All right, Let's continue in the next video.