1
00:00:02,180 --> 00:00:07,340
Let's have a look at that schema thing and let's think about the options we have.

2
00:00:07,400 --> 00:00:14,840
So obviously, we can have a totally chaotic approach as I showed you in that last little example with

3
00:00:14,840 --> 00:00:22,190
totally different documents and one and the same collection or we follow a SQL worldlike approach

4
00:00:22,490 --> 00:00:29,180
where we make sure that all elements, all entries have exactly the same schema and there is no extra

5
00:00:29,180 --> 00:00:31,560
entry on any document.

6
00:00:31,670 --> 00:00:36,800
So we got the whole bandwidth and we of course, we also got some shades in between,

7
00:00:37,070 --> 00:00:41,490
so in the chaos world, we basically got what we just saw in the little example,

8
00:00:41,660 --> 00:00:46,710
we got maybe a products collection with totally different products in there,

9
00:00:46,790 --> 00:00:53,240
so that is possible in mongodb but it's probably not what you need or what you'll use in reality.

10
00:00:53,750 --> 00:00:56,030
Maybe you're somewhere in between,

11
00:00:56,120 --> 00:00:59,160
you got some kind of schema, for example here

12
00:00:59,180 --> 00:01:06,020
all my products have a title and a price but you got some extra information on some of your documents,

13
00:01:06,110 --> 00:01:11,250
so there is maybe some extra data on some documents but the general schema is the same

14
00:01:11,300 --> 00:01:16,730
and there probably are some core fields which exist on every document.

15
00:01:16,730 --> 00:01:22,580
Well or you got the other extreme where all documents have exactly the same structure, like here.

16
00:01:23,060 --> 00:01:31,730
Now anything is possible here, you can go with any of the three solutions or any step in-between depending

17
00:01:31,730 --> 00:01:34,260
on how you need it in your application

18
00:01:34,460 --> 00:01:41,630
but in reality, I guess either the approach on the right or most often the one in the middle is what you

19
00:01:41,630 --> 00:01:42,970
will see in reality

20
00:01:43,160 --> 00:01:45,790
because there, you use the best of both worlds.

21
00:01:45,830 --> 00:01:52,250
You have some structure because your usecase, your application probably needs it but you also take advantage

22
00:01:52,250 --> 00:01:58,050
of the flexibility mongodb gives you so that you can store extra information, that by the way is also

23
00:01:58,130 --> 00:02:04,060
possible in the SQL world, there maybe you would have a null value for some fields,

24
00:02:04,220 --> 00:02:09,880
well in the middle world, you simply omit a field if you have no data and you assign a value to the field

25
00:02:09,890 --> 00:02:13,080
if you do. So that is really a mixture,

26
00:02:13,340 --> 00:02:15,440
in the end go with whatever works for you,

27
00:02:15,500 --> 00:02:21,080
the case in the middle and the case on the right are the more realistic ones or the ones you see more

28
00:02:21,080 --> 00:02:21,440
often

29
00:02:21,440 --> 00:02:25,080
in reality I guess though. Back in my collection,

30
00:02:25,130 --> 00:02:27,880
let me quickly clear my products here

31
00:02:30,460 --> 00:02:37,330
with deleteMany and there I'll simply pass an empty pair of curly braces to delete all my entries,

32
00:02:37,330 --> 00:02:39,060
so that now it's empty

33
00:02:39,250 --> 00:02:49,890
and now in there, let me again insert some products, insertOne and I want to to show the two approaches,

34
00:02:49,890 --> 00:02:52,160
which are the most realistic ones.

35
00:02:52,200 --> 00:02:56,900
Let's go with the middle approach first, which might be the one you see most often,

36
00:02:56,910 --> 00:03:00,410
there you have a name like a book,

37
00:03:00,570 --> 00:03:06,260
you got a price like 12.99 and that's maybe it for the first product and then you enter another

38
00:03:06,300 --> 00:03:12,990
product and that product also will have a name and a price because these are probably some core fields

39
00:03:13,260 --> 00:03:19,420
which every product needs in your application because on the page you rendered to your users, on a website

40
00:03:19,420 --> 00:03:19,690
.

41
00:03:19,690 --> 00:03:24,120
let's say, you probably want to show at least a name and a price.

42
00:03:24,150 --> 00:03:30,680
So for our other product, a T-shirt, simply the value changes

43
00:03:30,730 --> 00:03:34,140
but the fields are the same and the names of these fields also are,

44
00:03:34,150 --> 00:03:36,010
whoops, I hit enter accidentally,

45
00:03:36,010 --> 00:03:41,310
of course I should enter price here like 20.99.

46
00:03:41,310 --> 00:03:46,430
So now if I look into my products here and I pretty print that, we see

47
00:03:46,440 --> 00:03:48,650
both elements are in there. Now

48
00:03:48,660 --> 00:03:51,360
this is the case on the right, the SQL world,

49
00:03:51,390 --> 00:03:55,400
we got exactly the same structure, just the values differ.

50
00:03:55,510 --> 00:03:57,850
Now you might have another product,

51
00:03:57,990 --> 00:04:09,930
let's say a computer and of course that also has another price like this but this might now also

52
00:04:09,990 --> 00:04:15,490
have an extra field, details maybe. Let's say in your shop,

53
00:04:15,490 --> 00:04:21,550
not every element has details because maybe a book for some reason doesn't require details,

54
00:04:21,550 --> 00:04:26,560
obviously you could argue a book and a T-shirt also have detail data but this is just an example, let's

55
00:04:26,560 --> 00:04:34,710
say our computer has some details because there, we basically have the CPU and that is the text where

56
00:04:34,710 --> 00:04:42,020
we have Intel i7, some build number, like this.

57
00:04:42,290 --> 00:04:47,050
If I add this and now I find all my documents, we are in the middle world,

58
00:04:47,180 --> 00:04:53,780
we got a core structure which every document fulfills, like a name and a price exists on every document,

59
00:04:53,780 --> 00:04:59,610
a little side note here is that the price actually does not always have the same kind of data,

60
00:04:59,780 --> 00:05:05,930
it looks like it always has a number and that is true but we switch between a double number, so number

61
00:05:05,930 --> 00:05:11,260
with decimal places and an integer, a number without decimal places but that's a side note,

62
00:05:11,330 --> 00:05:13,080
I'll come back to data types.

63
00:05:13,100 --> 00:05:19,070
So generally we have the same though, name and price but then we get some extra information on one product

64
00:05:19,250 --> 00:05:23,630
and that might be something that works for your application too because there, you could of course

65
00:05:23,630 --> 00:05:28,450
have some code which always displays the name and the price but only displays the details

66
00:05:28,520 --> 00:05:34,520
if available and therefore we can reflect this in our data and we now are in that middle column of the last

67
00:05:34,520 --> 00:05:35,330
slide.

68
00:05:35,660 --> 00:05:39,830
So this is one of the more realistic cases you'll have in mongodb

69
00:05:39,920 --> 00:05:41,960
and this is a totally fine way of using it.

70
00:05:42,050 --> 00:05:47,650
Well all the use cases were fine but this is one you'll encounter in practice too

71
00:05:47,930 --> 00:05:55,070
or of course, you have exactly the same fields for all your products. Just to showcase this really quick,

72
00:05:55,070 --> 00:06:02,180
I'll again go into my products database and delete all my products in there with deleteMany and let's

73
00:06:02,180 --> 00:06:08,870
say we want to have that same structure we had before but now, we want to have that in a way where all

74
00:06:08,990 --> 00:06:13,310
documents have exactly the same fields and that is possible,

75
00:06:13,520 --> 00:06:21,290
if I repeat my insert commands here for the book, we would simply set details equal to null, null is a

76
00:06:21,290 --> 00:06:23,960
value which you can assign to indicate that

77
00:06:23,990 --> 00:06:28,720
well there is no value but there is the field available then.

78
00:06:28,820 --> 00:06:32,620
So if we do that and we do the same for the tshirt here,

79
00:06:32,840 --> 00:06:40,880
so we also have the details set to null there and I then also enter my computer, if I now find all products

80
00:06:40,880 --> 00:06:46,910
and pretty print them, we see the difference to before is that we still have no detailed data for

81
00:06:46,910 --> 00:06:49,870
the first two products, only for the third one

82
00:06:50,210 --> 00:06:56,750
but now we still have that field in there. That is the more SQL-ish approach I'd say because the structure

83
00:06:56,750 --> 00:07:03,710
is now exactly equal in all documents except for that number thing which I mentioned, the price is a different

84
00:07:03,710 --> 00:07:04,550
type of number

85
00:07:04,700 --> 00:07:07,390
but otherwise it's exactly the same structure

86
00:07:07,670 --> 00:07:13,580
and this might also be an approach you use because you like the clarity of having exactly the same fields

87
00:07:13,610 --> 00:07:19,250
everywhere and you simply indicate that no value is available by setting the value to null.

88
00:07:19,400 --> 00:07:21,320
Now here you can take either approach,

89
00:07:21,320 --> 00:07:27,800
it's probably a bit more MongoDB-ish to simply get rid of details if it holds no value

90
00:07:27,860 --> 00:07:32,160
but ultimately this is also up to you and you could take this route too.

91
00:07:32,180 --> 00:07:34,600
There is no single best practice here,

92
00:07:34,640 --> 00:07:40,930
you can go with whichever approach works better for you or whichever approach you personally prefer.