Now, in this course section,
as I mentioned before,
we're going to build a basic blog website,
which will look like this,
and which will allow us to browse blog posts,
to add new blog posts,
where we also have a dropdown with predefined authors
that can be assigned to blog posts.
and we're then, of course, also going to be able
to view individual blog posts.
And we'll, of course, also be able to add
or delete blog posts.
So we've got all these CRUD operations
incorporated into this website.
So that's what we're going to build.
And this slide here is actually from the MySQL
and NodeJS course section.
We're going to build the same thing with NoSQL
and MongoDB here,
but there will be an important difference
when it comes to the steps we're going to go through.
With MySQL, we planned and designed
our databases and tables.
And we then created those database tables.
And then we added some initial data.
With NoSQL and MongoDB, of course,
the step where we create databases and tables
will be skipped.
And we're also going to plan our database layout
a little bit differently.
We're mostly going to think
about the queries we will be running.
And then decide which collections we want,
and how the documents should look like.
And then we're still going to add some initial data,
but not through some graphical user interface,
but instead with help of the MongoDB shell,
which we also used before, in the course already.
Now, last but not least, then of course,
as the most important part of this course section,
you are then going to see how you can also connect
and talk to that database from inside
the NodeJS/Express backend code.
Now, therefore let's dive right in
and plan our database structure.
And as you learned, when it comes to planning
your database structure, and which collections you want,
and how your documents should look like,
in a NoSQL database, then you actually wanna start
by thinking about the queries you'll be running.
Are you going to do a lot of writing to the database?
A lot of inserting or a lot of reading?
For a lot of websites, it's more reading than writing,
but of course that's not necessarily true for every website.
And then once you made that decision,
it, of course, is important to understand
which kind of data are you going to write or read.
And you then want to create collections
that actually minimize the effort of running
those write or read queries.
Now, in this website, which we're going to build here,
we are building a blog.
And whilst of course, we do have capabilities for adding
and deleting and updating blog posts.
There probably won't be
multiple blog posts added every minute.
So there won't be a lot of writing,
only some occasional write operations.
On the apprehend, it is, of course, fair to assume
that for a blog, there will be a lot of data fetching.
We will hopefully have a lot of visitors
who view this starting page with all the blog posts
or who then also viewed the individual blog posts.
So we will often fetch all the blog posts
or single blog posts, which we identify by ID.
And therefore, we want to plan our collections for that.
Now, of course, it makes sense that therefore
create a collection that holds all our posts.
That we create a posts collection,
which then stores our post documents.
So every blog post is a standalone document
in that post's collection.
And then every document in this post collection
should have some unique identifier, this unique ID,
which thankfully will be created automatically
by MongoDB for us.
And then of course, it's up to you how a blog post
should look for you.
For me, it will have a title,
so the main title of the blog post.
Then a short summary text,
which I show on the page where we list all the blog posts.
Then the detailed full text body
that belongs to every blog post,
which you can see if you visit the detailed page
of a single blog post.
And of course, I also want to have a date snapshot,
which basically tells me when this blog post was created.
And that will also be part of the data
we show to the user in the end.
And then there's a never key element
and never a key piece of data
that's attached to every blog post.
And that should be information about the author
of the blog post.
Now, here's something important though,
when it comes to this author,
it's not just attached to the blog post,
but we also need to be able to get
a list of available authors when we add a new blog post,
because there, I want to have a dropdown
where you can choose from a predefined list of authors.
So that you can't come up with arbitrary names
or introduce typos when typing the author name.
But that instead, this is a fixed list of predefined values
and those values should be coming from the database as well.
So that, again, you can't introduce errors
by mistyping or anything like that.
And therefore we will actually also have
a second collection of authors.
And there, I wanna have a unique identifier per author.
And then let's say the name
and email address of each author.
And we will actually pre-populate
this author's collection ahead of time.
Our website won't have a section or a site
where you can add new authors.
Though, of course, as an extra bonus task,
you could try to add such a site to it.
But instead here, we will just assume
that some global administrator
is administrating the list of authors.
And therefore, that will be some data,
which we actually add through the MongoDB shell,
and which we then can use in the website
for populating this dropdown,
and for connecting blog posts to authors.
But speaking off that,
of course, a blog post should be affiliated with an author.
And therefore we will store the idea of an author
for a given blog post.
But I'll not just do that.
In the MySQL world, we would just have stored the ID
and then we would have joined the data together
when we need the combined data.
When we also need the name of the author.
But here, for example, when I show a list of all blog posts,
I do wanna show that author name here.
I don't need to email address here.
But it would be a bit annoying if we have to always join
the two collections here
for displaying a list of blog posts.
If we would have to run two different query stale for.
Remember that our goal always is to reduce the amount
of queries and we would not achieve this here.
Therefore, I will actually also store the author name
in my blog posts collection.
So the ID, and then also the name of and affiliated
of a related author for a given blog post document.
Of course, the name therefore, will be duplicated.
It's in the different blog post documents,
and it's in the authors collection documents
in one of the documents there.
But that shouldn't be a huge issue.
It would be a huge issue if the name would change
all the time, because then we have to change it
in both the authors collection
and possibly in a lot of documents in the posts collection.
But names typically don't change that often.
So this kind of duplication won't be a problem.
We could also duplicate the email address,
so that we never have to run an unnecessary second query
to get this data.
And we might implement this for all this course section,
but of course, email addresses could change
more frequently than names.
So there, it really comes down to request
to whoever that is data that you expect to change a lot.
In which case, duplicating it would be bad
because when it changes,
you will have to attach a lot of documents,
which is bad for performance
and is a lot of work you have to do.
If you don't expect email addresses to change a lot,
you could also duplicated that
into your blog posts documents,
so that you actually never have to run queries reaching out
to two different collections at the same time
to get some merged data.
Because unlike with MySQL,
there is no join operation that you could run
on the database level,
instead, for NoSQL databases like MongoDB.
If you want to join data from multiple collections,
you'll have to do it manually.
So I'll come back to that when we have the problem later on,
but that's the general structure I plan on implementing.
And throughout this course section,
you'll see how that works,
which potential challenges we face,
and how we can run queries efficiently
with that plan layout here.
Now, with all of that,
it's therefore time to leave the theory
and dive into our project.
And get started by adding or by connecting to MongoDB.
And then also get started with adding blog posts and so on.