EDWARD'S LECTURE NOTES:
More notes at http://tanguay.info/learntracker
C O U R S E
MongoDB for Node.js Developers
Andrew Erlichson, MongoDB University
 |
C O U R S E L E C T U R E Comparing RDBMS and MongoDB Schema Design Notes taken on June 18, 2014 by Edward Tanguay |
•
schema design
•
in RDBMS it is best to keep it in the third normal form
•
in Mongo, it is more important to keep the data in a way that the data will be used, e.g. keep together the data that is:
•
used together
•
used read-only
•
written
•
basic facts of mongodb
•
rich documents
•
not just tabular data
•
can store key/value
•
can store arrays
•
can store complete document on key
•
it's most important to realize that there are no joins
•
so you have to think what data you want to use with other data
•
no constraints
•
no foreign key constraints
•
not as important because of embedding
•
no transactions
•
but there are atomic operations
•
no declared schema
•
but a good chance that each document in each collection will have a similar structure
•
relational world: third normal form
•
you have a posts table
•
post_id, title, body, author, author_email
•
not third normal form because emails are repeated for each author
•
what are the good aspects of having a database in third normal form?
•
1. frees database of modification anomalies
•
in MongoDB, you have to be careful not to create these anomalies
•
if you can't avoid it, you can keep it up to data in the application, e.g. make sure that like author/email pairs are always the same
•
2. minimizes redesign when extending
•
Mongo is good at this, because of flexible schemas
•
3. avoids bias toward any particular access pattern
•
but in MongoDB, you don't worry about this, because if you are not biased to one particular access pattern, you are equally bad at all of them
•
schema for blog project
•
user name is immutable
•
the users that leave comments on the blog are not logged in so those emails are not redundant
•
tags are strings so they aren't redundant
•
so this is still not a violation of the 3rd normal form
•
when we display it we have everything we need in the same place
•
alternative schema for blog project
•
separate collections for posts, comments, tags
•
we could do this, but the problem is, we don't have any kinds of joins inside MongoDB
•
so you will have to manually collect this in code
•
this will be tedious
•
there is no locality of data
•
one good rule of thumb
•
if you are designing your schema in the same way as in RDBMS, you are probably doing it wrong