Inless video we said that we could somehow fix the problem of getting duplicate votes on a single survey
from a single user fixed by recording the list of recipients in a sub document collection.
And we had said that for every one of these sub documents which referred to as a recipient they would
all have an email property and a clipped property as well.
Now I want to talk to you a little bit more about some document collections how they work and how they
differ from normal collections.
First off I'm going to give you a better visual of what's going on here.
Look at this is a diagram of our overall surveys collection.
Remember that the instant we created a new survey model as we just did right here we get a new collection
inside of our Mongo database that stores a list of surveys and we refer to this as the surveys collection.
So inside of that surveys collection we have a bunch of different instances of surveys where a bunch
of different records that represent a single survey.
Now we can store a variety of records inside of this survey that we refer to as a sub document collection.
So each one of these is a recipient.
Now you might ask why would we use some document collections at all.
Well the answer is that we use them whenever we want to make a very very clear association between two
given records.
So a recipient right here like this very particular recipient with an e-mail and they clicked property
only ever will belong to its parent survey and this recipient really has absolutely no use whatsoever
in the context of any other survey inside the surveys collection.
So in other words the recipient is only useful as a child of this survey.
It's not useful in any other regard whatsoever.
And I would kind of have to stretch my mind to think of a case where we would care at all about this
recipient outside of just belonging to this given survey.
So we usually make use of some document collections like this when we want to make some type of ownership
relationship very very clear.
Now when I say that your immediate answer might be.
OK Stephen.
So every survey has a list of recipients and we record those as a sub document collection.
But you had also just told us two minutes ago Stephen that our users have a list of surveys.
So in that case why do our surveys have a reason.
Why does a user have references to these other surveys they've created.
And why does the user not have surveys listed as a sub document collection something like this.
So in this kind of case I know this diagram diagram is a little bit hard to pick up right here.
But in this case I'm saying why don't we have just a single collection user's collection.
And then inside of there every user has a sub document collection of surveys and then every survey has
a sub document collection of recipients.
So why don't we go all the way with the nesting wireless kind of setting up this nesting.
On one level but not the other.
Well I got to tell you there is a very practical reason for this.
Very practical.
So in the Mongo D-B world we refer to each of the records inside of a collection as a document.
So looking at the users collection right here we have a document a document a document and then inside
of the survey collection we have a document that is a survey and that includes everything inside of
it.
So really this is one whole document.
This is one whole document.
So I missed the little drag right there.
So here's one whole document and then another whole document right here as well.
So that is relevant.
And let me tell you why this is going to be quite interesting.
So when ever we use Mongo D-B the size limit for a very particular record is four megabytes.
That's it.
You can only ever stuff four megabytes worth of data into a single document.
So in other words we are saying that this survey right here in all of the data inside of it can only
ever be up to four megabytes large.
So let's kind of do a little bit of math here.
Let's do a little bit of math.
If we take my personal e-mail address as a benchmark and we say that my e-mail is like the average length
of an e-mail address Well my email is 20 bytes large and I've got a little calculator over here to prove
it.
So I put in my email and it says 20 characters.
Yep that's 20 bytes.
So my email address if we assume that it's an average length email it's 20 bytes long.
If you take that 20 bytes long right here and multiply it by 200000 you instantly get up to about 4
megabytes.
So in other words a single survey can only actually store about 200000 e-mail addresses.
Anyways now thinking about a survey that's definitely ok like I could imagine that we would kind of
top out around 200000 e-mails for a very individual survey.
That's definitely something I could palet it's something that I could approach my customers if I was
trying to sell this application and say hey just you know we've got a hard limit on surveys of 200000
recipients and I think that's a very reasonable limit.
You know that's pretty darn large.
However I want you to now imagine what would happen if we change this schema up a little bit.
And we said that every user's list of surveys was stored in the user record where the user document
has a subcollection.
So in other words if we were in this type of situation well if we still had that four megabyte limit
and we do we have it every time we whenever we use Mongo it's always a limit of four megabytes.
And we are now saying that a user can only ever send out 200000 emails worth of surveys.
So if this right here was a survey that contained 100000 emails or 100000 recipients who all of a sudden
the user only has an additional hundred thousand recipients to work with before we can no longer physically
associate any data with their account.
And so as you can imagine this would lead to some really really really crazy bugs inside of our application
because we would have these super power users in our application who are sending out surveys nonstop
and they're giving us a ton of money because they're sending out all these surveys and then all of a
sudden one day they say hey I can't seem to do any more surveys created and then we check our database
logs and we find out that oh boy there is actually a limit to how many emails this single user can send
out.
And that would be very close to a worst case scenario.
I will tell you right now that would be a very bad thing to have happen.
So answering the question of why we set up a sub document collection for the recipient list right here.
But we did not set up one very similarly for the list of surveys.
It's all about physical limitations of Mongo DB.
OK.
So in this video we spoke about some document collections.
We said that they are a great way to kind of associate records or indicate ownership of records but
that we need to be a little bit careful of it and be very aware of the data that we are storing inside
of Mongo.
And make sure that we have some reasonable idea of how many records can fit into a sub document collection.
So with that in mind let's continue in the next video and we're going to talk a little bit more about
how we set up a sub document collection of recipients.
So I'll see you in just a minute.