1
00:00:02,260 --> 00:00:04,210
We had to look at one-to-one relations,

2
00:00:04,210 --> 00:00:09,580
let's now have a look at one-to-many relations. Let's say like in the Q&A section of Udemy,

3
00:00:09,580 --> 00:00:14,800
we have question threads and each question thread then has a couple of answers,

4
00:00:14,800 --> 00:00:19,690
so an answer only belongs to one thread but a thread can have multiple answers,

5
00:00:19,810 --> 00:00:22,700
that's a typical one-to-many relationship.

6
00:00:22,720 --> 00:00:25,450
How would you model that in MongoDB?

7
00:00:25,690 --> 00:00:34,780
For that, I'll create a support database and in there, I might have my question threads collection and there,

8
00:00:34,800 --> 00:00:38,110
I insert one new question thread

9
00:00:38,110 --> 00:00:42,040
in the end. There we might have like a Creator Max,

10
00:00:42,310 --> 00:00:47,990
so the person who opened this thread then we got the question,

11
00:00:48,140 --> 00:00:50,660
how does that all work,

12
00:00:50,660 --> 00:00:53,990
by the way not how you should pose a question but more details please.

13
00:00:53,990 --> 00:00:55,430
But that is the question

14
00:00:55,430 --> 00:01:00,170
and then we get the answers and now the question is how do we model the answers?

15
00:01:00,410 --> 00:01:06,740
We could go for a seperate collection with the answers and only store the IDs to the answers here,

16
00:01:06,950 --> 00:01:15,050
so there we could have q1a1 as an ID and maybe we also have q1 for question 1 of course, a2

17
00:01:15,050 --> 00:01:16,450
as an ID.

18
00:01:16,460 --> 00:01:22,730
So now if I access my question threads and I find that one question I have in there, we see we're now taking

19
00:01:22,730 --> 00:01:24,260
that reference approach again,

20
00:01:24,260 --> 00:01:30,090
we have an array of IDs and that would mean we would now also create an answers collection

21
00:01:30,170 --> 00:01:35,700
and there insert many answers because now I want to have two at least because I have two references

22
00:01:35,700 --> 00:01:37,280
here, so to complete them all,

23
00:01:37,290 --> 00:01:37,940
let's insert

24
00:01:37,970 --> 00:01:39,620
two answers.

25
00:01:39,620 --> 00:01:42,400
I assign my own ID because I'm using my own ID,

26
00:01:42,440 --> 00:01:47,810
again we could have created it in a different order and then use the objectId in the answers array

27
00:01:47,810 --> 00:01:48,300
here

28
00:01:48,440 --> 00:01:52,280
but here I'm doing it like this and then we get an answer with a text,

29
00:01:52,280 --> 00:02:01,100
it works like that and I will insert a second document. Important for insertMany,

30
00:02:01,140 --> 00:02:06,740
we wrap the documents we insert in square brackets so we insert an array,

31
00:02:07,140 --> 00:02:13,770
so the second document in that array then also has an ID, that ID is q1a2 to fit that reference we

32
00:02:13,770 --> 00:02:16,110
stored and there the text is

33
00:02:16,140 --> 00:02:17,140
thanks.

34
00:02:17,610 --> 00:02:22,710
And obviously an answer would probably also have like ID of the person who created it or the embedded

35
00:02:22,710 --> 00:02:23,700
person data

36
00:02:23,730 --> 00:02:25,640
but let's not worry about that right now.

37
00:02:25,860 --> 00:02:34,500
If I hit enter, the two elements were added and now again, we can of course look into our answers and

38
00:02:34,500 --> 00:02:39,320
see the two answers there and we can then manually match that as we did it earlier.

39
00:02:39,360 --> 00:02:46,380
We could retrieve the question threads and on the question threads, we could now simply store the different

40
00:02:46,380 --> 00:02:53,310
IDs and the answers in in variables and then make requests to the answers collection and look for these

41
00:02:53,310 --> 00:02:56,850
IDs and we don't have to make two requests, later

42
00:02:56,850 --> 00:03:05,280
Manuel will show you how you could also search for all elements that fit an array of IDs you are looking

43
00:03:05,280 --> 00:03:05,690
for,

44
00:03:05,700 --> 00:03:07,700
so you don't always have to look for one ID,

45
00:03:07,710 --> 00:03:12,030
you can say hey give me all documents that are this ID, this ID or this ID,

46
00:03:12,390 --> 00:03:15,220
so it's still one extra request though.

47
00:03:16,810 --> 00:03:21,050
Here again embedding might be the better solution,

48
00:03:21,190 --> 00:03:28,260
so in question threads, I'll first of all delete all existing documents to start from scratch

49
00:03:28,780 --> 00:03:34,070
and now again, I will add my question thread

50
00:03:34,100 --> 00:03:38,960
with insertOne here. Now again probably I'll have a creator,

51
00:03:39,230 --> 00:03:40,580
I have the question text,

52
00:03:40,580 --> 00:03:43,150
how does that work

53
00:03:43,190 --> 00:03:48,480
and then I have my answers and the answers now are not references but a list of documents.

54
00:03:48,710 --> 00:03:53,990
And there I could have my first answer with the text like that

55
00:03:53,990 --> 00:04:01,230
and then I have a second answer, so a second document in that list of documents with a text of thanks.

56
00:04:01,950 --> 00:04:08,400
And now with that, if I save that and we open our question threads and look into the first question with

57
00:04:08,400 --> 00:04:09,500
findOne,

58
00:04:09,870 --> 00:04:12,820
well then we see now we have that embedded approach,

59
00:04:12,920 --> 00:04:17,550
now a list of embedded documents because it's a one-to-many relationship,

60
00:04:17,550 --> 00:04:22,800
so we have many documents but still it's embedded documents which we're using here

61
00:04:23,040 --> 00:04:29,100
and for a scenario like this and a similar scenario for example would be posts and comments related

62
00:04:29,100 --> 00:04:29,990
to posts

63
00:04:30,000 --> 00:04:36,420
makes sense to be modelled like this because often, you need to fetch the questions along with the answers,

64
00:04:36,450 --> 00:04:42,960
so from application requirement perspective, you want to fetch the merged data and we also don't have

65
00:04:44,040 --> 00:04:47,850
thousands of answers on one thread typically,

66
00:04:47,850 --> 00:04:55,090
so we also don't have the danger of bloating our document and maybe reaching that 16mb limit

67
00:04:55,110 --> 00:05:01,620
we have for a document. So that is not a problem here and therefore this might be a perfect use case

68
00:05:01,830 --> 00:05:05,400
for embedding documents in a one-to-many relationship.