Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this 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.
Resources:
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:
Part 1
Part 2
Part 3
MongoDB documentation on data modelling
MDN page detailing Array.prototype.sort
JavaScript Patterns, by Stoyan Stefanov, is a great book on writing solid JavaScript code. On page 134, Stoyan Stafanov shows how to write a recursive deep-extend function.
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 = …).
-
0:00
[MUSIC]
-
0:04
Now that we have an idea of how Mongoose works, let's add it to our application.
-
0:09
Before we can write the schemas we still need to know how we're going to associate
-
0:13
question and answer objects in Mongo itself.
-
0:17
Mungo is optimized for storing infection single documents quickly, while working
-
0:23
with multiple documents is possible it can come at a performance cost.
-
0:28
To work with Mongo and not against it, it's best to associate the data
-
0:32
together by wrapping all the data in a single document and
-
0:36
handing it over to Mongo for storage.
-
0:39
For our question and answer objects, that will mean we're only creating
-
0:43
one collection, a questions collection, concerning question objects,
-
0:48
along with an additional property and a rate that holds the child answer objects.
-
0:55
That way, a question and it's entire collection of answers
-
0:59
is encapsulated together and can be retrieved with one database call.
-
1:04
While this is often the preferred way to structure a parent child
-
1:08
relationship in Mongo, there are reasons you may want to break up parents and
-
1:12
children into separate collections.
-
1:16
One reason would be if there are more than a few hundred children,
-
1:21
Mongo documents have a sixteen megabyte limit and
-
1:25
a few hundred children documents could start to stretch the parent to the limit.
-
1:30
At that point, it might make sense to create a separate collection for
-
1:34
the children and store their ID's in an array in the parent.
-
1:38
While this eases the size of the parent document,
-
1:42
it also results in more transactions to the database.
-
1:46
Now that the data has been broken up into several documents.
-
1:50
ID transaction numbers reduced performance.
-
1:53
Keep such tradeoffs in mind as you structure your applications data.
-
1:58
If you expect the number of children to be in the thousands, it may be possible that
-
2:02
the parent will reach the 16 megabyte limit with the IDs alone.
-
2:07
In this case, you'd want to remove the array of children from the parent document
-
2:12
and store the parent's ID in each of its children.
-
2:16
For a deeper look at this topic,
-
2:18
I've supplied some links in the teacher's notes.
-
2:21
In our API, we won't be expecting more than 20 answers per question.
-
2:25
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