1
00:00:02,260 --> 00:00:09,190
Now in the last lecture we saw one-to-one relationship where we want to have an embedded document.

2
00:00:09,250 --> 00:00:16,570
Now for many, probably most one-to-one relationships, you'll probably go with the embedded document but you're

3
00:00:16,570 --> 00:00:17,980
not forced to,

4
00:00:17,980 --> 00:00:23,800
you could also have one-to-one relationships where you still opt to use different collections

5
00:00:23,800 --> 00:00:26,530
and here is a possible example.

6
00:00:26,860 --> 00:00:31,980
Let's say we got a couple of persons and a couple of cars and I'm not talking about car models here,

7
00:00:32,080 --> 00:00:40,630
so not BMW, Mercedes, Ford but let's say we have a person and the car this person owns and therefore this

8
00:00:40,630 --> 00:00:46,210
is a one-to-one relation because this car cannot be owned by a different person and that person

9
00:00:46,210 --> 00:00:48,960
could of course theoretically own multiple cars

10
00:00:48,970 --> 00:00:53,630
but let's say each person can only own one car.

11
00:00:54,010 --> 00:01:00,110
So we have a one-to-one relation then, one car per person and one person per car.

12
00:01:00,160 --> 00:01:06,030
Now we could of course still model this with an embedded document, in a brand new mongodb server,

13
00:01:06,280 --> 00:01:08,670
let's add a new collection,

14
00:01:08,780 --> 00:01:12,510
use car data, whatever you want to call it,

15
00:01:12,510 --> 00:01:13,470
so that's the database and

16
00:01:13,470 --> 00:01:21,470
now let's add a new collection there. We could go for persons and insert one person here and that one person

17
00:01:21,950 --> 00:01:28,700
will have a name, Max let's say and will have a car and that car is a nested or embedded document where

18
00:01:28,700 --> 00:01:37,520
I then have the model, BMW and let's say a price, 40000.

19
00:01:37,520 --> 00:01:42,520
Now of course I can fetch my persons and get back the car with it

20
00:01:42,560 --> 00:01:48,110
and that might be fine for a lot of applications but let's say we're not creating some web app where

21
00:01:48,110 --> 00:01:54,050
we need to render both on the same screen but maybe we have more of an analytics use case,

22
00:01:54,290 --> 00:02:02,420
so we have a use case where we are very interested in analyzing person data like average salary or age,

23
00:02:02,720 --> 00:02:07,990
all data I don't have in my dummy data here but we can of course add more data depending on the app.

24
00:02:08,060 --> 00:02:14,600
So we're interested in analyzing our persons and we might be interested in analyzing our cars but not

25
00:02:14,600 --> 00:02:20,270
so much in a relation, that might occasionally be interesting too but maybe we also want to do a lot

26
00:02:20,270 --> 00:02:25,260
of averaging, a lot of analytics on the persons or the cars.

27
00:02:25,280 --> 00:02:29,690
So here we have an application driven reason for splitting this up,

28
00:02:29,690 --> 00:02:35,420
there is no hard reason, its perfectly fine theoretically to merge that into one collection as we are

29
00:02:35,420 --> 00:02:41,840
currently doing it but due to our application needs, this might not be optimal because if we only interested

30
00:02:41,840 --> 00:02:47,960
in the cars, there is no need to fetch all the persons just to get to their cars, that would actually

31
00:02:47,960 --> 00:02:53,630
means we have to do a lot of transformation work to extract the car data and we send a lot of unnecessary

32
00:02:53,630 --> 00:02:55,370
data over the wire.

33
00:02:55,700 --> 00:03:00,230
And the other way around too, if we're only interested in the person data, I don't care about the cars,

34
00:03:00,260 --> 00:03:04,340
so we again would have to do a lot of unnecessary transformation work.

35
00:03:04,340 --> 00:03:12,590
So such an application driven requirement or need could be a reason for splitting this up, for other applications,

36
00:03:12,710 --> 00:03:14,860
merging it might be perfectly fine.

37
00:03:14,900 --> 00:03:22,980
So here we could go for an approach where I delete all persons just to clean it up

38
00:03:23,360 --> 00:03:29,240
and then I again insert a person again, insert one but this time let's say that is our person with the

39
00:03:29,240 --> 00:03:37,410
name and an age and a salary, like this.

40
00:03:37,620 --> 00:03:41,990
And now we have a possibility of fetching all the persons,

41
00:03:42,030 --> 00:03:46,030
typically we would of course have more than one and do analytics on that

42
00:03:46,110 --> 00:03:50,360
and if we are interested in the cars, we have these in a separate collection.

43
00:03:50,460 --> 00:03:56,850
So there we can insert our car data, like model BMW,

44
00:03:59,340 --> 00:04:08,250
price 40000 and then here also, maybe the owner and that could be a reference to some ID we define or

45
00:04:08,320 --> 00:04:09,790
here probably

46
00:04:09,870 --> 00:04:13,970
we would go for the ID which we have, the automatically generated objectId,

47
00:04:14,140 --> 00:04:15,520
so let's store that.

48
00:04:15,540 --> 00:04:23,430
So now we still have the possibility to relate the car to an owner, that is possible and the person, we

49
00:04:23,430 --> 00:04:29,310
could now also store the ID of the car if we wanted to depending on whether we often will have fetched

50
00:04:29,310 --> 00:04:32,820
persons and now also want to get the car or the other way around.

51
00:04:33,270 --> 00:04:37,980
We got some link, that is they key take away so we can merge the data if we want to

52
00:04:38,040 --> 00:04:42,800
but if we commonly don't do that, we don't have to use an embedded document,

53
00:04:42,810 --> 00:04:44,970
we can go for different collections here.

54
00:04:45,120 --> 00:04:51,000
So that would be one possible use case where you use different collections even though you could perfectly

55
00:04:51,000 --> 00:04:51,930
embed it.