Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Now that we have some idea of how Mongoose works, we can build an interface our application will use to access the database. Before we can write the schemas, though, we still need to know how we're going to associate question and answer objects in Mongo itself.
Blog series about Modelling one-to-many (AKA parent-child) relationships in MongoDB:
6 Rules of Thumb for MongoDB Schema Design, By William Zola, Lead Technical Support Engineer at MongoDB:
MDN page detailing Array.prototype.sort
Also, studying source code is a great way to learn! Here's jQuery's implementation of $.extend.
Skip down to line 124 (the line may move, so you can also use the browser's find in page and type in 'extend' to see where it is defined
(jQuery.extend = …).
Now that we have an idea of how Mongoose works, let's add it to our application.
Before we can write the schemas we still need to know how we're going to associate
question and answer objects in Mongo itself.
Mungo is optimized for storing infection single documents quickly, while working
with multiple documents is possible it can come at a performance cost.
To work with Mongo and not against it, it's best to associate the data
together by wrapping all the data in a single document and
handing it over to Mongo for storage.
For our question and answer objects, that will mean we're only creating
one collection, a questions collection, concerning question objects,
along with an additional property and a rate that holds the child answer objects.
That way, a question and it's entire collection of answers
is encapsulated together and can be retrieved with one database call.
While this is often the preferred way to structure a parent child
relationship in Mongo, there are reasons you may want to break up parents and
children into separate collections.
One reason would be if there are more than a few hundred children,
Mongo documents have a sixteen megabyte limit and
a few hundred children documents could start to stretch the parent to the limit.
At that point, it might make sense to create a separate collection for
the children and store their ID's in an array in the parent.
While this eases the size of the parent document,
it also results in more transactions to the database.
Now that the data has been broken up into several documents.
ID transaction numbers reduced performance.
Keep such tradeoffs in mind as you structure your applications data.
If you expect the number of children to be in the thousands, it may be possible that
the parent will reach the 16 megabyte limit with the IDs alone.
In this case, you'd want to remove the array of children from the parent document
and store the parent's ID in each of its children.
For a deeper look at this topic,
I've supplied some links in the teacher's notes.
In our API, we won't be expecting more than 20 answers per question.
We can store the entire array for each question in a single question document.
You need to sign up for Treehouse in order to download course files.Sign up