1
00:00:02,190 --> 00:00:06,610
Ok, so we learned a lot about schemas and relations, let's practice that a bit.

2
00:00:06,700 --> 00:00:11,910
And here's a simple example project which I want you to think about how you would structure the data

3
00:00:11,950 --> 00:00:12,640
for it

4
00:00:12,640 --> 00:00:14,730
and then of course we'll also do it together.

5
00:00:15,130 --> 00:00:21,820
So we have our user in our application and that can be a server side rendered website, a single page application,

6
00:00:22,030 --> 00:00:24,440
a mobile app, anything like that.

7
00:00:24,490 --> 00:00:30,090
We've got our app server and in that app server or to that app server, we send a couple of different requests because

8
00:00:30,090 --> 00:00:36,820
let's say we're building a blog as the title says, so users are able to create posts, edit posts, delete

9
00:00:36,820 --> 00:00:41,070
posts, fetch all posts so that we can display a list of posts on a page,

10
00:00:41,170 --> 00:00:48,550
fetch a single post so we can read that post and also comment posts, so we can write comments and we

11
00:00:48,550 --> 00:00:51,940
can also fetch these comments of course to display them.

12
00:00:51,940 --> 00:00:56,960
Now we got our application server with our code being being written in nodejs

13
00:00:56,980 --> 00:00:59,740
and .NET, PHP. We won't write the code here,

14
00:00:59,740 --> 00:01:01,620
this is not a web development course,

15
00:01:01,630 --> 00:01:07,940
we won't write any code here, we'll just structur the data for that and see how such a dummy request, how

16
00:01:07,960 --> 00:01:13,420
such a write or such an edit could look like, our code in a real app would of course use the mongo driver,

17
00:01:13,420 --> 00:01:18,750
we will use the shell here and in the end it will send the data the requests to the server.

18
00:01:18,880 --> 00:01:27,400
So our goal here now in this exercise is to simply define a schema, identify the core entities we have

19
00:01:27,400 --> 00:01:33,310
in this world and how the schemas for these entities could look like, how they are related and how we would

20
00:01:33,310 --> 00:01:35,560
model these relations

21
00:01:35,560 --> 00:01:40,370
and then we'll just play around with some queries so that we can see how our application,

22
00:01:40,370 --> 00:01:44,090
how the mongodb driver would interact with our database,

23
00:01:44,110 --> 00:01:45,290
so let's have a look.

24
00:01:45,310 --> 00:01:50,540
I'm drawing on my iPad here and as I mentioned, definitely go ahead, do this on your own,

25
00:01:50,590 --> 00:01:51,390
definitely

26
00:01:51,430 --> 00:01:57,400
layout the core data entities you have and how they might look like in your application and how they

27
00:01:57,400 --> 00:01:58,570
could be related,

28
00:01:58,570 --> 00:02:03,030
there is no single correct solution here but I'll go well with my approach now.

29
00:02:03,280 --> 00:02:05,670
So which kinds of data do we have?

30
00:02:05,860 --> 00:02:12,290
Well in our single blog, we have at least a user,

31
00:02:12,500 --> 00:02:21,800
we have our posts, so we have a single post and we'll also have a comment because users can comment posts,

32
00:02:22,030 --> 00:02:29,260
so these three data entities here should exist. Now which kind of data

33
00:02:29,480 --> 00:02:31,430
does a user consist of,

34
00:02:31,430 --> 00:02:34,690
does a post consist of and does a comment consist of?

35
00:02:35,090 --> 00:02:45,020
They will all have that underscore ID of course because that is a hard requirement by mongodb,

36
00:02:45,610 --> 00:02:54,450
then a user might have a name, might have an age and might have an email

37
00:02:54,470 --> 00:03:03,530
let's say, a post might have a title, might have a text and whatever else you want,

38
00:03:03,560 --> 00:03:11,890
maybe some tags and obviously you might come up with totally different fields here.

39
00:03:11,930 --> 00:03:14,470
Now that is how that could look like, a comment

40
00:03:14,630 --> 00:03:17,280
will simply have some text, let's say.

41
00:03:17,600 --> 00:03:20,270
How are these entities now related?

42
00:03:20,720 --> 00:03:26,230
Well a user can create a post

43
00:03:26,350 --> 00:03:29,960
and of course edit and delete it then,

44
00:03:30,410 --> 00:03:36,000
a user can also comment a post,

45
00:03:36,100 --> 00:03:44,120
so a post can have multiple comments where each comment also knows which user created the comment. These

46
00:03:44,120 --> 00:03:46,220
are the general relations we have in there,

47
00:03:46,460 --> 00:03:48,480
how could we now model that?

48
00:03:48,890 --> 00:03:56,690
Well we got the whole variety of things, we could embed everything, we could go with one collection only,

49
00:03:57,360 --> 00:04:03,200
let's say the post collection is our only collection I want to go with it and in posts,

50
00:04:03,200 --> 00:04:13,330
we then have our user and that is an embedded document which holds the user data as defined here

51
00:04:14,600 --> 00:04:26,980
and in post, we also have our comments which is basically an array of nested documents,

52
00:04:26,980 --> 00:04:32,760
sorry for my super ugly drawings but here we would have that comment data in array.

53
00:04:32,770 --> 00:04:41,110
So this would be the only collection we then have, posts with embedded users in a single post or the

54
00:04:41,110 --> 00:04:44,480
embedded user and embedded comments.

55
00:04:44,650 --> 00:04:46,620
Now is that a good approach?

56
00:04:47,380 --> 00:04:50,750
Well parts of it are good,

57
00:04:50,920 --> 00:04:58,580
I'm fine with embedding my comments here because the comments are a one-to-many relationship,

58
00:04:58,650 --> 00:05:02,630
a post can have many comments but a comment always belongs to one post.

59
00:05:02,870 --> 00:05:08,580
A post also typically doesn't have millions of comments so we probably don't hit any mongodb

60
00:05:08,580 --> 00:05:09,300
limit

61
00:05:09,480 --> 00:05:16,340
and we often want to fetch a post along with its comments. So nesting the comments here might be fine,

62
00:05:16,350 --> 00:05:20,880
you can always go for a different solution but I'm fine with nesting comments.

63
00:05:21,020 --> 00:05:22,580
What about nesting the user?

64
00:05:22,860 --> 00:05:24,230
I don't think that is a good idea,

65
00:05:24,240 --> 00:05:31,200
Nesting the user doesn't sound too good to me because if we nest a user here, then we have a problem

66
00:05:31,320 --> 00:05:37,150
because one user can create many posts, so if the user data then changes,

67
00:05:37,410 --> 00:05:43,190
let's say if the e-mail changes, we have to edit that user in all the posts,

68
00:05:43,230 --> 00:05:49,410
so we've got a lot of duplicate data and whilst that might not change on a daily basis, it certainly

69
00:05:49,410 --> 00:05:56,130
is not like a user never changes any data, so it's not such a low frequency that I would be fine with

70
00:05:56,130 --> 00:05:59,220
doing all these duplicate changes when they occur.

71
00:05:59,580 --> 00:06:03,440
So I'm a fan of actually creating two collections here,

72
00:06:03,680 --> 00:06:12,430
the users collection and the post collection, we'll not have a comment collection, we'll have comment data

73
00:06:12,430 --> 00:06:19,030
in this structure, in our array here but we'll not have a separate collection for comments. Instead we'll have have

74
00:06:19,570 --> 00:06:26,280
posts and users and we'll use these collections with some embedded documents for comments and also for tags

75
00:06:26,290 --> 00:06:27,390
by the way, tags

76
00:06:27,430 --> 00:06:33,520
also in the end is just an just an array of strings so we could also say that this is a relation to different tags.

77
00:06:34,030 --> 00:06:37,320
So we have two major collections, posts and users,

78
00:06:37,330 --> 00:06:43,600
this is my solution and I hope my explanations here are clear why I would not use a comments collection

79
00:06:43,780 --> 00:06:49,040
even though you can of course do that and why I would not use nested users.

80
00:06:49,040 --> 00:06:54,000
Now let's go back to the shell and play around a bit with that and see how we could implement that

81
00:06:54,010 --> 00:06:54,310
there.