MongoDB with Async Python Transcripts
Chapter: Document Databases
Lecture: How Document Databases Work
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
How do document databases work? Well, let's look at a real world example from TalkByThun training.
0:08
Here is one of the chapter records that we store about our courses.
0:13
For our chapters, we have information about them as well as all the videos and details about those videos that make up that particular chapter.
0:23
So we're going to walk through this one real quick and see how we might understand it, how we might ask questions about it, and so on.
0:30
You can think of it as having kind of two different aspects, a traditional database
0:35
aspect, this green, and something weird and unique, like a foreign key constraint or a
0:41
join or something like that in a relational database for the embedded records. So we have traditional columns, if you will.
0:50
They're not called that in MongoDB, but you know, from a relational database, that would be the analogy. We have ID, underscore ID.
0:57
This is always the name of the primary key. And then we have title, course ID, and duration in seconds.
1:05
All of those are standard things you could model in any other relational database such as Postgres or SQLite. Then we have lectures.
1:14
And notice that lectures is not just a foundational type like a number or a string. It is nested objects.
1:22
So we've got details about the different lectures, the welcome and thanks for coming, the Linux
1:27
and installing, and so on. So you can think of this part here as like a pre computed join.
1:35
And this is part of what makes document databases super, super fast. At runtime, when you ask
1:42
questions about the database, instead of going, well, first, we have the chapter and now let's
1:48
go query stuff out of this big lecture table, bring a bunch of pieces together and compute
1:53
something about that and then return those results, you just say, ""Give me something by ID. Here is the answer.
2:00
And it already comes pre-joined with this lecture data because for us, if you need details
2:07
about the chapter, you almost always need details about the videos in that chapter as well, the lectures.
2:15
So we modeled our data to say, ""Well, if you're going to need them together almost all the time anyway, when you get one, just return them all.
2:25
That's great. I'm sure it sounds awesome in terms of performance, but there's an interesting question, like
2:31
can you ask questions about this data like you would be able to if they were not mushed together in this pre-joined nested way?
2:40
So for example, what if you just want to know I need the chapter that contains the lecture with ID 10106? Is it possible to even answer that question?
2:51
Is it possible to answer it quickly, say with an index? And yes, absolutely, you can do those kind of queries.
2:58
You can ask questions about arbitrarily deep nested objects, and you can do that with an index.
3:04
So it would be just as fast to say, give me the chapter that has a lecture with this ID
3:10
as it would be to ask for the chapter itself by primary key, for example.
3:16
And that's why this nesting is still productive and useful because you can still do high-performance
3:22
queries about the nested data, not just the top-level data.