The Learn Tracker
...life-long learning: structured, organized, searchable...
924
Lectures Watched
Since January 1, 2014
Hundreds of free, self-paced university courses available:
my recommendations here
Peruse my collection of 275
influential people of the past.
View My Class Notes via:
Receive My Class Notes via E-Mail:

VIEW ARCHIVE

Contact Me via E-Mail:
edward [at] tanguay.info
Notes on video lecture:
Comparing RDBMS and MongoDB Schema Design
Notes taken by Edward Tanguay on June 18, 2014 (go to class or lectures)
Choose from these words to fill the blanks below:
modification, atomic, used, wrong, third, violation, similar, embedding, collect, access, arrays, logged, written, bad, flexible, immutable, joins, collections, tabular, extending, application
•
schema design
•
in RDBMS it is best to keep it in the            normal form
•
in Mongo, it is more important to keep the data in a way that the data will be         , e.g. keep together the data that is:
•
used together
•
used read-only
•
              
•
basic facts of mongodb
•
rich documents
•
not just                data
•
can store key/value
•
can store             
•
can store complete document on key
•
it's most important to realize that there are no           
•
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                   
•
no transactions
•
but there are              operations
•
no declared schema
•
but a good chance that each document in each collection will have a                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                          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                       , e.g. make sure that like author/email pairs are always the same
•
2. minimizes redesign when                   
•
Mongo is good at this, because of                  schemas
•
3. avoids bias toward any particular              pattern
•
but in MongoDB, you don't worry about this, because if you are not biased to one particular access pattern, you are equally        at all of them
•
schema for blog project
•
user name is                   
•
the users that leave comments on the blog are not              in so those emails are not redundant
•
tags are strings so they aren't redundant
•
so this is still not a                    of the 3rd normal form
•
when we display it we have everything we need in the same place
•
alternative schema for blog project
•
separate                        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                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           
MongoDB Introduction
Installing MongoDB/node.js and Hello Worlds
MongoDB, node.js, Express and SWIG
Basic Querying in MongoDB
More Querying in MongoDB
MongoDB CRUD via Node.js
Comparing RDBMS and MongoDB Schema Design