Now that we understand that we can use schema and that we probably will use them because our application typically
works with certain types of data, certain schemas and that we had a look at the data types you can use,
the different integers, text and so on,
now that we had a look at all of that,
let's see how we kind of think about modeling our schemas
and I want to give you some guidelines or hints that you can keep in mind when you think about how should
I structure my data. We'll not look at relations yet, I'll come to that next though
but thus far, let's see what we got.
And one important question is which data does my app need or generate
and the term app definitely should be understood in a very broad sense here,
this can be a mobile app, this can be a website,
it could be a smart device generating data like a tracker, a fitness tracker sending GPS coordinates,
so this is a very broad definition of app.
The idea is my business model you could say, which data does it need and or generate? And it could be anything,
user information, product information, orders, coordinates, anything like that
and this will define the fields you'll generally need
and of course also already
a bit how they relate. A user might order products,
so these are, this gives you the general frame for your data structure.
You then also have to think about where do I need my data,
so for example if you're building a website, do I need it on the welcome page, on the products list
page, on the orders page and which kind of data do I need on all these pages
because the idea with mongodb is that you store your data in the format you need it in your application
and if you need the same data in different formats, you want to find a good structure that covers all
these use cases
or if absolutely necessary, you could even split it into multiple collections.
So this defines your required collections, for example that you have an orders collection for the orders page,
that you have a product collection for the products page
and it also defines which fields you have in the documents of a collection and how you might group these
fields together, so how you might relate to these fields, more about relations in a second. You also should
ask yourself which kind of data or information do I want to display,
so on these different pages, which kind of data do I want to show on there
and then again defines which queries you will need then. So do I display a list of products or a single
product,
is it a find or findOne query,
how should I configure this query,
am I looking for a product with a specific ID or am I looking for all products and Manuel will take
a detailed look at how you can configure your find queries to narrow down the set of found products
of course.
These queries also or the kind of queries you plan also have an impact on your collections and your
document structure
because as I already said, mongodb really embraces that idea of planning your data structure
based on the way you'll retrieve your data, so that you don't have to do complex joins but that you can
retrieve your data in the format or almost in the format you need it in your application.
You also need to ask yourself how often do I fetch my data, on every page reload or every second or not
that often because that also tells you if you should optimize for easy fetching because you're fetching
a lot but maybe you're not writing data that much,
so you might be fine with having some duplicate data if that speeds up the fetching process because you
don't have to join data manually or do you often write and change your data. If you have an application
where your data gets changed a lot or parts of your data get changed a lot,
you want to ensure that these parts of the data that do get changed a lot,
let's say we have a lot of orders but the product metadata doesn't change that often,
you want to make sure that your orders are not unnecessarily duplicated across collections but that
you have one collection with your orders where you can write new orders too, product metadata on the other
hand might be distributed across different collections because well you don't change it that often,
so if you change it, you have to touch multiple collections but that's no problem,
the main focus is that you can fetch that data from the different parts of your application in the format
you need it.
So these are some things for you to keep in mind or to think about
and if that is a lot right now, that is totally normal.
No worries, we'll see all that throughout the course and we'll have many examples so that you can get a feeling
for well how you might approach that and how we would structure data in a certain scenario.
And one important thing that is related to these questions is of course the question about how you model
relations between different entities in your data
and that is what I'll take a look at next.