1
00:00:02,240 --> 00:00:08,660
So these are your relation options and I hope that the examples kind of gave you a feeling for how to

2
00:00:08,660 --> 00:00:14,540
think about relations and when to use which approach, it always depends on your application needs,

3
00:00:14,660 --> 00:00:18,220
how often you change data, if snapshot data does suffice

4
00:00:18,290 --> 00:00:23,750
and how large your data is, how much data you have. In general, with embedded documents,

5
00:00:23,750 --> 00:00:29,450
the idea is to group data together logically and often, that makes sense and gives you an easier time

6
00:00:29,450 --> 00:00:31,030
when fetching the data

7
00:00:31,250 --> 00:00:37,430
and that is great for data that belongs together, for one-to-many or one-to-one relations and that is

8
00:00:37,430 --> 00:00:39,480
not really overlapping with other data,

9
00:00:39,500 --> 00:00:46,160
so you got no many-to-many relation and where you're also not in danger to hit any limit imposed

10
00:00:46,160 --> 00:00:51,430
by mongodb and where you also don't need to split your data for application needs

11
00:00:51,470 --> 00:00:57,440
like we had in the person and car example here. You should avoid super deep nesting because you can only

12
00:00:57,440 --> 00:00:58,700
nest for 100 levels

13
00:00:58,710 --> 00:01:04,560
as you learned and again, keep that 16mb limit per document in mind

14
00:01:04,610 --> 00:01:08,380
and that also contains the embedded documents,

15
00:01:08,390 --> 00:01:13,780
so it's not 16mb per embedded document but for the overall document. That is a lot

16
00:01:13,910 --> 00:01:19,160
but for New York City with all its citizens, you would probably reach it.

17
00:01:19,430 --> 00:01:24,620
The alternative then is the reference approach, there you split your data across collections and that is

18
00:01:24,620 --> 00:01:27,250
great for related data, that is shared,

19
00:01:27,320 --> 00:01:33,470
so many-to-many relationships in the end or it's great for data where you would have a lot of duplicates

20
00:01:34,370 --> 00:01:39,560
which you'll update a lot and therefore you have the danger of needing to update a lot of documents

21
00:01:39,620 --> 00:01:46,160
all the time which is bad and it's also a great solution if you need to overcome any nesting or size

22
00:01:46,160 --> 00:01:46,760
limits,

23
00:01:46,850 --> 00:01:51,370
then you can simply split it across collections because that of course,

24
00:01:51,650 --> 00:01:57,570
well basically allows you to remove some levels of nesting.

25
00:01:57,600 --> 00:01:59,120
These are your options,

26
00:01:59,140 --> 00:02:04,370
there is no general formula but if you keep these general things in mind, how do I use my data,

27
00:02:04,390 --> 00:02:05,440
how often do I use it,

28
00:02:05,440 --> 00:02:09,850
how often do I change it and how is it related, one-to-one, one-to-many, many-to-many,

29
00:02:09,940 --> 00:02:16,020
if you go through all these points, you should be able to really create relations that work for you.