We had to look at one-to-one relations,
let's now have a look at one-to-many relations. Let's say like in the Q&A section of Udemy,
we have question threads and each question thread then has a couple of answers,
so an answer only belongs to one thread but a thread can have multiple answers,
that's a typical one-to-many relationship.
How would you model that in MongoDB?
For that, I'll create a support database and in there, I might have my question threads collection and there,
I insert one new question thread
in the end. There we might have like a Creator Max,
so the person who opened this thread then we got the question,
how does that all work,
by the way not how you should pose a question but more details please.
But that is the question
and then we get the answers and now the question is how do we model the answers?
We could go for a seperate collection with the answers and only store the IDs to the answers here,
so there we could have q1a1 as an ID and maybe we also have q1 for question 1 of course, a2
as an ID.
So now if I access my question threads and I find that one question I have in there, we see we're now taking
that reference approach again,
we have an array of IDs and that would mean we would now also create an answers collection
and there insert many answers because now I want to have two at least because I have two references
here, so to complete them all,
let's insert
two answers.
I assign my own ID because I'm using my own ID,
again we could have created it in a different order and then use the objectId in the answers array
here
but here I'm doing it like this and then we get an answer with a text,
it works like that and I will insert a second document. Important for insertMany,
we wrap the documents we insert in square brackets so we insert an array,
so the second document in that array then also has an ID, that ID is q1a2 to fit that reference we
stored and there the text is
thanks.
And obviously an answer would probably also have like ID of the person who created it or the embedded
person data
but let's not worry about that right now.
If I hit enter, the two elements were added and now again, we can of course look into our answers and
see the two answers there and we can then manually match that as we did it earlier.
We could retrieve the question threads and on the question threads, we could now simply store the different
IDs and the answers in in variables and then make requests to the answers collection and look for these
IDs and we don't have to make two requests, later
Manuel will show you how you could also search for all elements that fit an array of IDs you are looking
for,
so you don't always have to look for one ID,
you can say hey give me all documents that are this ID, this ID or this ID,
so it's still one extra request though.
Here again embedding might be the better solution,
so in question threads, I'll first of all delete all existing documents to start from scratch
and now again, I will add my question thread
with insertOne here. Now again probably I'll have a creator,
I have the question text,
how does that work
and then I have my answers and the answers now are not references but a list of documents.
And there I could have my first answer with the text like that
and then I have a second answer, so a second document in that list of documents with a text of thanks.
And now with that, if I save that and we open our question threads and look into the first question with
findOne,
well then we see now we have that embedded approach,
now a list of embedded documents because it's a one-to-many relationship,
so we have many documents but still it's embedded documents which we're using here
and for a scenario like this and a similar scenario for example would be posts and comments related
to posts
makes sense to be modelled like this because often, you need to fetch the questions along with the answers,
so from application requirement perspective, you want to fetch the merged data and we also don't have
thousands of answers on one thread typically,
so we also don't have the danger of bloating our document and maybe reaching that 16mb limit
we have for a document. So that is not a problem here and therefore this might be a perfect use case
for embedding documents in a one-to-many relationship.