O'Reilly Webcast: MongoDB Schema Design: How to Think Non-Relational
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- 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 within 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 webcast, 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.
About Jared Rosoff:
Jared is the Director of Product Marketing and Technical Alliances at 10gen. Before joining 10gen, Jared ran Product Development at Yottaa where he developed a real-time analytics engine on top of MongoDB and Ruby on Rails.
Produced by: Yasmina Greco
![[TH] FS vs BME - VCT Ascension Pacific - Lower Bracket Final](http://i.ytimg.com/vi/wnygqsR2Fig/mqdefault.jpg)
Awesome presentation and great Q&A.
The presentation does not address some key issues with database design and storage as they relate to RDBMS: composite keys, unique key validation, data type validation, incorrect field names/types. In the presentation: how would you remodel the existing data if a book now has joint authors? make authors an array, or break it out to a related collection. How would you model complex patterns: Example:
A customer has multiple orders (array). Each order has multiple lines (array). Each line has one product but the products have many attributes (related collection). Each order has zero, one or many deliveries (??). Each delivery can have multiple delivery lines (array). Each delivery line is linked to one and only one order line, but the order line may have many delivery lines - How would you build the relationship between the order line and delivery line as they both exist within the customer order history document (or within the order sub-document). The simplest way to do this is with a unique key on the order line (order line#) and reference that on the delivery line (deliveryLine#, OrderLine#FK) - effectively you have now created a RDBMS relationship within the document, but it is very difficult to index because the OrderLine# is relative to the order, which is not part of the indexable value at that level - I'll stick to 3rd Normal form thanks. :)
The presenter side steps issues such as referential integrity by saying that these are now the responsibility of your application or business logic layer - This means that your middle and front tier developers need to understand the database schema; whereas with RDBMS they can query the schema directly with their favorite ORM tool; know what values they are getting and are expected to set and simply have to deal with the errors when they post something that is not allowed (e.g. wrong data type, or a date that is in the past (use Check Constraint) )
The presenter also did not address a key issue of RDBMS which is transactional scope and the ability to roll back all the changes made within the transaction
I can see MongoDB and Firebase, which is based on Mongo as a great rapid development tool or where you have large amounts of data but it has a relatively short life span for high volume access (like 4Square and Twitter) but there is a reason 3NF relational databases have been around for a long time - they are very good at what they do!
Excellent presenter
good
Really helpful video!! After looking at few MongoDb videos, this one gave me what I was looking for - Moving from Relational to NoSQL model. Thanks!!
good
Amazing video. Very concise and perfect amount of information.
The RDBMS comparison was super helpful. I wonder it would actually have been easier if I didn't have a decade of RDBMS experience.
Nice topic. It certainaly helps. However I have to quibble. I think of RDB as an N-Space, not a table. If you think of it as rows and columns, as tables, you are doing it wrong.
I read somewhere (I think it was the "the little mongoDB book"), that it is to complement RDBMS or serve as alternative. I think what he was trying to say by mentioning magento was the point with difficult altering of the database model and then afterwards manipulating queries and relations between the tables, that goes along with modification of the model. He did not say explicitly, that mongoDB should replace it and I didn't feel any implied suggestions there too.
in my opinion he's justifying a huge mistake, sql is still fast! the hard drive 21:30 , sorry what?
Super helpful. This kind of translation like presentation is exactly what I needed as a MSSQL DBA.
Gr8 presentation, very helpful for learning, good didactic, but the advertising against Relational Databases, like Mongo and NoSQL is better in all aspects is misleading. As Aaron Reese, and some others pinpointed here, MongoDB is for some specific usages, and key value dont always provide the best performance, and specially the fastest and neatest development architecture.
That said, have to say this presentation addressed all you need to start developing in a very easy and fast way. Congrats.
Very nice video. Thanks.
It will be better if you can show the speaker also for some time. It will be more engaging than watching the slides alone.
consider an application that allows users to write comments about books
a book should know about it's comments - so I get the idea of comments as a collection within books
the application should list recent comments - so I get the idea of a relationship model
but neither successfully addresses the need for uses to see their own comments
would it not be better to have three silos - books with a collection of comments, users with a collection of comments and a collection of comments
writes would be slower as the data lives in three places, but reads are fast - updates would be fairly quick because the central comments collection could hold a reference to the author and the book.
or have I got the wrong idea here?
Great video for moving from relational or object model to NOSQL.
Awesome. It's kind of a tutorial, and feel the need to go back to stuffs.
so. any notes? Or pdf?
Yeah, that was kind of out of the blue, typical of presentations I've seen for new technologies before: "look how complicated this is, now let me show you the new version where all the complexity is hidden over here and harder to deal with"... I'm sure Magento being a commerce transaction system requires ACID compliance (or is much simpler knowing you have ACID compliance), and the pure MongoDB solution would be at least as complicated.
Good Session, something to take on board and to think about.
excellent presentation on MongoDB helps you translate the entity relationship in relational database to MongoDB
19:58:00 --> db.books.find({"comments.author":"Kyle"}) or SyntaxError
Thank you Jared, immensely helpful !
Very nice and clear explanation 👍🏻
Many to Many relationships modeling in MongoDB @35:00
mongodb is great, I've loved using it.
Very Helpful thanks
Finally I got the tagging and searching concept. Thanks..
This is the best video ever
Very useful, Thanks
Very helpful! Thanks!
Thanks!!....It was extremely helpful.
thanks for a very good presentation/introduction!
that annoyed the hell out of me
Nice :)... I like this technology !!!
Nice session. Very helpful ^_^
Outstanding presenter
nice presentation..
thank you so much
good
Cool stuff thanks
Thanks for this presentation!
great video! thanks!
Excellent!
I hate RDB. because it's hard to learn :D
Now I'm fonder of Firebase. Makes life easier :)
what about data duplication? what about efficient sorting? or caching? or concurrency problems? I would probably stick to relational....
You compare RDB's and NoSQL on huge sites that collect data on everything. You'll see how RDB databases use much more resources, and take longer to complete requests. This is fact. In the world of big data RDB databases don't work. I work in data science and I can tell you now that RDB's can not compare to NoSQL for big data. It'd take an awfully long time just to write the API's for the data I need at that given moment. With NoSQL I can get it done very quickly. You sound like you're hating. Learn them both, they are both useful in their own contexts.
Also normalisation doesn't exist in MongoDB, so asking someone to worry about normalisation in a database that doesn't encourage it is silly. Design your model better as Joey said.
Joe Seabreeze That's the answer! Just write flawless code!. ;)
housegeeksuk On any modern database engine you can turn off constraints, logging, normalize etc. to improve performance. Given recipe card normalization with fields which can contain arrays and JSON you basically have MongoDB. Also, buy large amounts of RAM and fast disks. I've run large DBs and never had performance issue (pushing TB range).
spanish please