Now in the last lecture we saw one-to-one relationship where we want to have an embedded document.
Now for many, probably most one-to-one relationships, you'll probably go with the embedded document but you're
not forced to,
you could also have one-to-one relationships where you still opt to use different collections
and here is a possible example.
Let's say we got a couple of persons and a couple of cars and I'm not talking about car models here,
so not BMW, Mercedes, Ford but let's say we have a person and the car this person owns and therefore this
is a one-to-one relation because this car cannot be owned by a different person and that person
could of course theoretically own multiple cars
but let's say each person can only own one car.
So we have a one-to-one relation then, one car per person and one person per car.
Now we could of course still model this with an embedded document, in a brand new mongodb server,
let's add a new collection,
use car data, whatever you want to call it,
so that's the database and
now let's add a new collection there. We could go for persons and insert one person here and that one person
will have a name, Max let's say and will have a car and that car is a nested or embedded document where
I then have the model, BMW and let's say a price, 40000.
Now of course I can fetch my persons and get back the car with it
and that might be fine for a lot of applications but let's say we're not creating some web app where
we need to render both on the same screen but maybe we have more of an analytics use case,
so we have a use case where we are very interested in analyzing person data like average salary or age,
all data I don't have in my dummy data here but we can of course add more data depending on the app.
So we're interested in analyzing our persons and we might be interested in analyzing our cars but not
so much in a relation, that might occasionally be interesting too but maybe we also want to do a lot
of averaging, a lot of analytics on the persons or the cars.
So here we have an application driven reason for splitting this up,
there is no hard reason, its perfectly fine theoretically to merge that into one collection as we are
currently doing it but due to our application needs, this might not be optimal because if we only interested
in the cars, there is no need to fetch all the persons just to get to their cars, that would actually
means we have to do a lot of transformation work to extract the car data and we send a lot of unnecessary
data over the wire.
And the other way around too, if we're only interested in the person data, I don't care about the cars,
so we again would have to do a lot of unnecessary transformation work.
So such an application driven requirement or need could be a reason for splitting this up, for other applications,
merging it might be perfectly fine.
So here we could go for an approach where I delete all persons just to clean it up
and then I again insert a person again, insert one but this time let's say that is our person with the
name and an age and a salary, like this.
And now we have a possibility of fetching all the persons,
typically we would of course have more than one and do analytics on that
and if we are interested in the cars, we have these in a separate collection.
So there we can insert our car data, like model BMW,
price 40000 and then here also, maybe the owner and that could be a reference to some ID we define or
here probably
we would go for the ID which we have, the automatically generated objectId,
so let's store that.
So now we still have the possibility to relate the car to an owner, that is possible and the person, we
could now also store the ID of the car if we wanted to depending on whether we often will have fetched
persons and now also want to get the car or the other way around.
We got some link, that is they key take away so we can merge the data if we want to
but if we commonly don't do that, we don't have to use an embedded document,
we can go for different collections here.
So that would be one possible use case where you use different collections even though you could perfectly
embed it.