Ok, so we learned a lot about schemas and relations, let's practice that a bit.
And here's a simple example project which I want you to think about how you would structure the data
for it
and then of course we'll also do it together.
So we have our user in our application and that can be a server side rendered website, a single page application,
a mobile app, anything like that.
We've got our app server and in that app server or to that app server, we send a couple of different requests because
let's say we're building a blog as the title says, so users are able to create posts, edit posts, delete
posts, fetch all posts so that we can display a list of posts on a page,
fetch a single post so we can read that post and also comment posts, so we can write comments and we
can also fetch these comments of course to display them.
Now we got our application server with our code being being written in nodejs
and .NET, PHP. We won't write the code here,
this is not a web development course,
we won't write any code here, we'll just structur the data for that and see how such a dummy request, how
such a write or such an edit could look like, our code in a real app would of course use the mongo driver,
we will use the shell here and in the end it will send the data the requests to the server.
So our goal here now in this exercise is to simply define a schema, identify the core entities we have
in this world and how the schemas for these entities could look like, how they are related and how we would
model these relations
and then we'll just play around with some queries so that we can see how our application,
how the mongodb driver would interact with our database,
so let's have a look.
I'm drawing on my iPad here and as I mentioned, definitely go ahead, do this on your own,
definitely
layout the core data entities you have and how they might look like in your application and how they
could be related,
there is no single correct solution here but I'll go well with my approach now.
So which kinds of data do we have?
Well in our single blog, we have at least a user,
we have our posts, so we have a single post and we'll also have a comment because users can comment posts,
so these three data entities here should exist. Now which kind of data
does a user consist of,
does a post consist of and does a comment consist of?
They will all have that underscore ID of course because that is a hard requirement by mongodb,
then a user might have a name, might have an age and might have an email
let's say, a post might have a title, might have a text and whatever else you want,
maybe some tags and obviously you might come up with totally different fields here.
Now that is how that could look like, a comment
will simply have some text, let's say.
How are these entities now related?
Well a user can create a post
and of course edit and delete it then,
a user can also comment a post,
so a post can have multiple comments where each comment also knows which user created the comment. These
are the general relations we have in there,
how could we now model that?
Well we got the whole variety of things, we could embed everything, we could go with one collection only,
let's say the post collection is our only collection I want to go with it and in posts,
we then have our user and that is an embedded document which holds the user data as defined here
and in post, we also have our comments which is basically an array of nested documents,
sorry for my super ugly drawings but here we would have that comment data in array.
So this would be the only collection we then have, posts with embedded users in a single post or the
embedded user and embedded comments.
Now is that a good approach?
Well parts of it are good,
I'm fine with embedding my comments here because the comments are a one-to-many relationship,
a post can have many comments but a comment always belongs to one post.
A post also typically doesn't have millions of comments so we probably don't hit any mongodb
limit
and we often want to fetch a post along with its comments. So nesting the comments here might be fine,
you can always go for a different solution but I'm fine with nesting comments.
What about nesting the user?
I don't think that is a good idea,
Nesting the user doesn't sound too good to me because if we nest a user here, then we have a problem
because one user can create many posts, so if the user data then changes,
let's say if the e-mail changes, we have to edit that user in all the posts,
so we've got a lot of duplicate data and whilst that might not change on a daily basis, it certainly
is not like a user never changes any data, so it's not such a low frequency that I would be fine with
doing all these duplicate changes when they occur.
So I'm a fan of actually creating two collections here,
the users collection and the post collection, we'll not have a comment collection, we'll have comment data
in this structure, in our array here but we'll not have a separate collection for comments. Instead we'll have have
posts and users and we'll use these collections with some embedded documents for comments and also for tags
by the way, tags
also in the end is just an just an array of strings so we could also say that this is a relation to different tags.
So we have two major collections, posts and users,
this is my solution and I hope my explanations here are clear why I would not use a comments collection
even though you can of course do that and why I would not use nested users.
Now let's go back to the shell and play around a bit with that and see how we could implement that
there.