1
00:00:02,260 --> 00:00:08,860
Now that we understand that we can use schema and that we probably will use them because our application typically

2
00:00:08,860 --> 00:00:15,880
works with certain types of data, certain schemas and that we had a look at the data types you can use,

3
00:00:15,880 --> 00:00:18,960
the different integers, text and so on,

4
00:00:18,970 --> 00:00:21,640
now that we had a look at all of that,

5
00:00:21,760 --> 00:00:26,630
let's see how we kind of think about modeling our schemas

6
00:00:26,680 --> 00:00:32,230
and I want to give you some guidelines or hints that you can keep in mind when you think about how should

7
00:00:32,230 --> 00:00:37,370
I structure my data. We'll not look at relations yet, I'll come to that next though

8
00:00:37,540 --> 00:00:40,590
but thus far, let's see what we got.

9
00:00:40,620 --> 00:00:44,930
And one important question is which data does my app need or generate

10
00:00:45,040 --> 00:00:49,820
and the term app definitely should be understood in a very broad sense here,

11
00:00:49,840 --> 00:00:52,260
this can be a mobile app, this can be a website,

12
00:00:52,330 --> 00:00:58,780
it could be a smart device generating data like a tracker, a fitness tracker sending GPS coordinates,

13
00:00:58,780 --> 00:01:01,290
so this is a very broad definition of app.

14
00:01:01,300 --> 00:01:08,780
The idea is my business model you could say, which data does it need and or generate? And it could be anything,

15
00:01:08,800 --> 00:01:13,780
user information, product information, orders, coordinates, anything like that

16
00:01:14,020 --> 00:01:16,710
and this will define the fields you'll generally need

17
00:01:16,810 --> 00:01:18,180
and of course also already

18
00:01:18,190 --> 00:01:22,430
a bit how they relate. A user might order products,

19
00:01:22,450 --> 00:01:27,490
so these are, this gives you the general frame for your data structure.

20
00:01:27,520 --> 00:01:31,260
You then also have to think about where do I need my data,

21
00:01:31,450 --> 00:01:36,340
so for example if you're building a website, do I need it on the welcome page, on the products list

22
00:01:36,340 --> 00:01:41,110
page, on the orders page and which kind of data do I need on all these pages

23
00:01:41,110 --> 00:01:48,310
because the idea with mongodb is that you store your data in the format you need it in your application

24
00:01:48,360 --> 00:01:53,480
and if you need the same data in different formats, you want to find a good structure that covers all

25
00:01:53,500 --> 00:01:54,430
these use cases

26
00:01:54,550 --> 00:01:59,950
or if absolutely necessary, you could even split it into multiple collections.

27
00:01:59,950 --> 00:02:06,640
So this defines your required collections, for example that you have an orders collection for the orders page,

28
00:02:06,820 --> 00:02:09,550
that you have a product collection for the products page

29
00:02:09,670 --> 00:02:15,400
and it also defines which fields you have in the documents of a collection and how you might group these

30
00:02:15,400 --> 00:02:22,140
fields together, so how you might relate to these fields, more about relations in a second. You also should

31
00:02:22,140 --> 00:02:26,330
ask yourself which kind of data or information do I want to display,

32
00:02:26,610 --> 00:02:31,340
so on these different pages, which kind of data do I want to show on there

33
00:02:31,380 --> 00:02:37,560
and then again defines which queries you will need then. So do I display a list of products or a single

34
00:02:37,560 --> 00:02:38,190
product,

35
00:02:38,220 --> 00:02:40,610
is it a find or findOne query,

36
00:02:40,770 --> 00:02:42,810
how should I configure this query,

37
00:02:42,810 --> 00:02:49,770
am I looking for a product with a specific ID or am I looking for all products and Manuel will take

38
00:02:49,770 --> 00:02:55,850
a detailed look at how you can configure your find queries to narrow down the set of found products

39
00:02:55,860 --> 00:02:56,960
of course.

40
00:02:57,130 --> 00:03:02,700
These queries also or the kind of queries you plan also have an impact on your collections and your

41
00:03:02,700 --> 00:03:03,710
document structure

42
00:03:03,720 --> 00:03:10,440
because as I already said, mongodb really embraces that idea of planning your data structure

43
00:03:10,770 --> 00:03:17,160
based on the way you'll retrieve your data, so that you don't have to do complex joins but that you can

44
00:03:17,160 --> 00:03:23,080
retrieve your data in the format or almost in the format you need it in your application.

45
00:03:23,100 --> 00:03:30,630
You also need to ask yourself how often do I fetch my data, on every page reload or every second or not

46
00:03:30,630 --> 00:03:37,500
that often because that also tells you if you should optimize for easy fetching because you're fetching

47
00:03:37,500 --> 00:03:40,470
a lot but maybe you're not writing data that much,

48
00:03:40,650 --> 00:03:46,350
so you might be fine with having some duplicate data if that speeds up the fetching process because you

49
00:03:46,350 --> 00:03:54,180
don't have to join data manually or do you often write and change your data. If you have an application

50
00:03:54,180 --> 00:03:58,350
where your data gets changed a lot or parts of your data get changed a lot,

51
00:03:58,350 --> 00:04:02,430
you want to ensure that these parts of the data that do get changed a lot,

52
00:04:02,460 --> 00:04:07,380
let's say we have a lot of orders but the product metadata doesn't change that often,

53
00:04:07,440 --> 00:04:13,710
you want to make sure that your orders are not unnecessarily duplicated across collections but that

54
00:04:13,710 --> 00:04:19,400
you have one collection with your orders where you can write new orders too, product metadata on the other

55
00:04:19,400 --> 00:04:25,200
hand might be distributed across different collections because well you don't change it that often,

56
00:04:25,200 --> 00:04:29,190
so if you change it, you have to touch multiple collections but that's no problem,

57
00:04:29,190 --> 00:04:34,610
the main focus is that you can fetch that data from the different parts of your application in the format

58
00:04:34,750 --> 00:04:35,700
you need it.

59
00:04:36,030 --> 00:04:39,490
So these are some things for you to keep in mind or to think about

60
00:04:39,600 --> 00:04:42,500
and if that is a lot right now, that is totally normal.

61
00:04:42,600 --> 00:04:47,910
No worries, we'll see all that throughout the course and we'll have many examples so that you can get a feeling

62
00:04:47,910 --> 00:04:54,140
for well how you might approach that and how we would structure data in a certain scenario.

63
00:04:54,150 --> 00:04:59,790
And one important thing that is related to these questions is of course the question about how you model

64
00:04:59,850 --> 00:05:03,360
relations between different entities in your data

65
00:05:03,360 --> 00:05:05,520
and that is what I'll take a look at next.