So let's now come back to that example,
which we briefly touched on over the last lectures
and which we also used in the SQL,
introduction section with the restaurants at the reviews.
In the last lectures,
of course I only added some basic restaurant data
because I wanted to get started
with the general MongoDB query syntax
and the CORS operations,
but now I want to discuss how we would really build
such a restaurants and reviews application
from a database point of view,
when working with a no SQL database.
And for that let's first of all,
come back to what we did in the SQL sections
in the SQL world, how that looked like there.
And there, we ended up with this structure,
we built four different tables, one for the restaurants,
then one for the addresses of the restaurants
and one for the types,
and these tables were linked together through relations.
And then we had the reviews table,
which was also connected to restaurants, through a relation.
And the idea here was that with SQL,
we want to have those clear structures.
We want to have those flat records
and those normalized data records.
And it's absolutely normal and wanted in the SQL world
that we work with multiple tables.
Now in the no SQL world,
that's not the main idea.
Instead as you learned before in this section
with no SQL databases,
you typically plan for the queries you are about to run
in your application.
So from your NodeJS server, so to say,
and you want to store your data such that your queries
can be as simple and efficient as possible
when working with no SQL,
therefore instead of setting up a structure like this
and working with four tables as we did it with SQL,
when working with no SQL, in this case with MongoDB,
we could set up a structure like this,
where we work with free collections to the end.
Now, of course,
there will always be more than one possible implementation,
but let me explain why I think
that this implementation here might be a good idea.
I'm working with three collections here.
And my main idea is that I store all the data
for my restaurants in the restaurants collection.
I'll come back to the types collection in a second.
Now to be precise,
I have to name for my restaurant stored
in the restaurant's collection,
and then also all the address details.
And that's of course,
a difference to the SQL world
where we had a separate addresses database table.
Now I do store the address as a nested object
in my restaurants documents because,
it's tightly, coupled to my restaurants,
chances are high that in my application,
when I fetch a list of restaurants,
I also need the addresses, and I don't want
to get that from a extra collection from before,
and in addition,
the address of a restaurant is not going to change a lot.
and not a lot of addresses will have the same address.
It can occur if they're in some kind of shopping mall,
but typically every restaurant will have its own address.
So therefore having the address data as a nested object
will be pretty good.
It will help be with querying,
with fetching the data.
And if I need to change an address,
I probably only need to do it for one or a few restaurants.
So I don't need to touch a lot of restaurant documents
to do that.
Now for it to type it's a bit more tricky.
Here I'm also a fan of storing the type directly
for my restaurant, since I'll typically query that together.
And that generally would also be good.
The type is probably not going to change a lot,
probably never for a restaurant.
So I don't need to touch this a lot, but of course,
I don't want to have one restaurant that's labeled American
and another restaurant that's labeled USA Food.
I don't think anyone would use this term,
but you get the idea.
I don't want to have different type labels,
if we're in the end talking about the same type,
but we just wrote them differently.
That's why we might want
to add a third extra types collection,
which stores all the predefined types,
which we then could use in a form that we present
to a user, inside of a dropdown
to choose a type from,
so that this is not a free text field,
but instead a list of predefined types.
But then once we store our restaurant,
we store the idea of the type
and the types collection for completeness sake.
But we also just copied the name of the type directly
into the restaurant's collection.
Therefore we'll have some duplicate data
because the type name, the human readable name
will be part of both the restaurant's documents,
as well as off the documents in the types collection.
But since those types will probably never change,
this kind of duplicate data is no problem.
If we would change them a lot,
we would have to update the type names
in two different collections and in a lot of documents,
which would be a nightmare.
But since German will always be named German,
as a restaurant type, we will never have to change it
in any places.
And therefore having this kind of duplicate data
is a good idea.
You could also work without that separate types collection,
but for the reasons mentioned,
to ensure that you don't enter arbitrary values,
we could have that separate collection year.
And then, we also want to have some reviews.
Now we could store reviews as a nested array
for every restaurant document.
Every restaurant document could have a reviews field,
which is an array off review objects,
but one restaurant can of course have hundreds
or thousands of reviews.
And with MongoDB or no SQL in general,
you want to avoid having nested data
that can grow infinitely,
also because there is a size limit
for the maximum size a document may have.
And you might go beyond that limit
if you have such infinite lists.
So you don't want to do that.
If you have a possibly infinite list of data,
you want to put that into a separate collection,
not into some nested field in a document
in another collection.
That's why we should have a separate reviews collection
where we store all the reviews.
And then there, of course,
we point at the restaurant to which a review belongs
with the restaurant ID.
We could even store some extra restaurant data
like the restaurant name here,
side-by-side with the restaurant ID
in our review documents.
So that when we fetch a list of reviews,
we also have that restaurant name at hand,
that depends on which kind of queries
you will be running later,
and if you need that restaurant name together
with your reviews a lot or not,
at chances are that you do,
and then duplicating that restaurant name
into the review documents might be a good idea,
also because the restaurant name is also not going
to change a lot,
So you won't need to update it in dozens or hundreds
of reviews all the time.
For fast changing data,
you want to avoid duplication
for data that barely ever changes.
You can absolutely duplicated it to make your queries
for fetching the data more efficient.
And then, that's how I store my data here.
And I think I will go for the extra
restaurant names stored in addition
to the restaurant ID in my reviews.
And therefore this will be the final structure
I will implement over the next lectures.
And of course as always, feel free to try storing that data,
creating that data on your own,
work with some dummy data
and these free collections,
maybe clear the existing documents you have
in your restaurants collection already
from the last lectures.
And then try building this on your own.
Over the next lectures,
we're going to set up the structure
and store some dummy data together.