Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword or section
Like this
8Activity
0 of .
Results for:
No results containing your search query
P. 1
MongoBoulder - Schema Design

MongoBoulder - Schema Design

Ratings: (0)|Views: 4,392 |Likes:
Published by Alvin John Richards
chema Design: Data as Documents
One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don't always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense. Understandably, this begets good questions:
Are foreign keys permissible, or is it better to represent one-to-many relations withing a single document?
Are join tables necessary, or is there another technique for building out many-to-many relationships?
What level of denormalization is appropriate?
How do my data modeling decisions affect the efficiency of updates and queries?

In this session, we'll answer these questions and more, provide a number of data modeling rules of thumb, and discuss the tradeoffs of various data modeling strategies.
chema Design: Data as Documents
One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don't always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense. Understandably, this begets good questions:
Are foreign keys permissible, or is it better to represent one-to-many relations withing a single document?
Are join tables necessary, or is there another technique for building out many-to-many relationships?
What level of denormalization is appropriate?
How do my data modeling decisions affect the efficiency of updates and queries?

In this session, we'll answer these questions and more, provide a number of data modeling rules of thumb, and discuss the tradeoffs of various data modeling strategies.

More info:

Published by: Alvin John Richards on Jan 21, 2011
Copyright:Traditional Copyright: All rights reserved

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

10/09/2013

pdf

text

original

 
Schema DesignAlvin Richardsalvin@10gen.com
 
Topics
Introduction
Basic Data Modeling
Evolving a schemaCommon patterns
Single table inheritance
One-to-Many & Many-to-Many
Trees
Queues
 
So why model data?
http://www.flickr.com/photos/42304632@N00/493639870/

Activity (8)

You've already reviewed this. Edit your review.
machristmann liked this
1 thousand reads
1 hundred reads
gambess liked this
Axel Ruballos liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->