You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

72 lines
4.7 KiB
Plaintext

00:01 We've come to a pretty exciting part in the course,
00:03 we're going to talk about document design
00:05 and modeling with document databases.
00:08 So let's take a step back and think about relational databases.
00:11 There is in fact a couple of really systematic, well known,
00:15 widely taught ways of modeling with relational databases;
00:20 there's still a bit of an art to it, but basically it comes down to
00:24 third normal form, first normal form, some of these well known ways
00:29 to take your data, break them apart, generate the relationships between them,
00:33 so if we're going to model like a bookstore with publishers
00:36 and users who buy books at the bookstore,
00:38 and they rate books at the bookstore, it might look like this—
00:41 we have a book, the book would have a publisher,
00:44 so there is a one to many relationship from publisher to books,
00:47 you can see the one on the star and the little relationship there,
00:50 and we have some flat properties like title and published
00:52 and publisher id for that relationship, and similarly,
00:55 we have a navigational relationship over to the ratings,
00:58 so a book is rated, so the ratings would have almost normalization table
01:03 or many to many table there has the book id and the user id
01:06 and then the value and we just happen to have a auto increment id there,
01:10 it's not necessarily the way we have to do it,
01:13 we could have a composite key, we've got our user
01:15 and the user can go navigate to the ratings, and things like that.
01:17 Now, of course, this is a very simplified model
01:20 in a real bookstore with real ecommerce happening and all that
01:23 and categories and pictures and all those things,
01:26 this would be way more complicated,
01:28 but the whole idea going forward is going to be pretty similar
01:30 and I think keeping it simple enough that you quickly understand the model
01:34 and don't get lost in the details, is the most important thing here.
01:37 So this more or less follows third normal form here.
01:40 in terms of how we're modeling this in the relational database.
01:44 Could we move this to MongoDB, could we move this to a document database—
01:47 sure, we could have exactly the structure.
01:50 Now those relationships, those are not full on foreign key constraints,
01:52 those would be loosely enforced, not enforced in the database
01:56 but enforced in the app relationships between the what would be collections;
02:00 but certainly, we could do this, is it the best way though?
02:03 The answer is usually not, maybe, but probably not.
02:07 So what we're going to focus on now is how do we take our traditional knowledge
02:12 of modeling databases and relational databases
02:14 and how does that change, what are the trade-offs we have to deal with
02:18 when we get to a document database.
02:20 So the good news is, usually things get simpler in document databases
02:24 in terms of the relationships, you might have
02:27 what would have been four or five separate tables with relationships,
02:31 it might get consumed into a single item,
02:34 a single collection or single document really,
02:36 so here this is how we're going to model our bookstore
02:40 that we just looked at in third normal form, but now in a document database.
02:43 And really, the right choice here comes down to
02:46 how is your app using this data, what type of questions do you usually ask,
02:50 what's the performance implications, things like this.
02:53 So now we have a books, we have a publisher and a user
02:56 and these have similar top level items,
02:58 and we do have some traditional relationships.
03:01 So there's a one to many relationship between publisher and books
03:05 theoretically we can embed the book into the publisher
03:08 but there's many, many books for some publishers
03:10 and that would be really a bad idea;
03:12 so we have this traditional relationship, like you might have in a relational database.
03:15 Now again, not enforced by Mongo, but enforced by your app, so same basic idea.
03:19 Next up, we have the ratings, remember we have that
03:22 like many to many table from users to book ratings,
03:26 now that has actually moved and now we're storing these items
03:30 in an embedded array of objects inside the book table, or the book collection.
03:35 So now each book has a ratings array, it has the number of ratings,
03:39 those are just put right in there, so is this the right design— maybe,
03:43 it's certainly a possible design, and it's the design that we're going to go with
03:47 for our examples, but we'll talk about when it's actually the right design.
03:51 And I'll help you make those trade-offs next.