Joe you’re a great instructor. Starting with the context/use case and then referencing the parts is so appreciated. Your channel is wildly underrated. Also love the humor references.
@JoeKarlsson Жыл бұрын
Thank you so much. I really appreciate that.
@BHVampireLF3 жыл бұрын
I didn´t wanted to watch a 1 hour video, I think is the first time I do something like this, and wow. I learned more in one hour than in 2 days readding weird written tutorials, guides and short videos. Thank you very much.
@JoeKarlsson3 жыл бұрын
Oh my gosh! That's awesome! I'm so glad it was useful for you! :)
@alejandromedina6494 жыл бұрын
I'm new at using MongoDB and this video has solved many doubts I had about how to design the ideal schema for my project. Thank you very much!
@JoeKarlsson4 жыл бұрын
This is the best thing I have ever heard - thank you!
@DIZZLEBOI443 жыл бұрын
@@JoeKarlsson have a mongodb/admin job coming up
@JoeKarlsson3 жыл бұрын
@@DIZZLEBOI44 Nice!
@Ikilledthebanks Жыл бұрын
What’s the easiest way to manage streams from mongo into snowflake using Kafka. The data structure changes and the update replace does not include data elements of the prior record. We require only the most recent update to the record no history
@toneking9724 жыл бұрын
Super helpful. I was on the fence with PostgreSQL and MongoDB. But this convinced me to go Mongo
@JoeKarlsson4 жыл бұрын
This is the best feedback - thank you so much!
@MohamedAsfer4 жыл бұрын
WoW. Really enjoyed this session. Thanks for the effort
@JoeKarlsson4 жыл бұрын
Thank you so much! I am so glad you enjoyed it!
@DaDa-gr7cy3 жыл бұрын
Great video, these intermediate videos are what youtube is lacking
@JoeKarlsson3 жыл бұрын
Right? I feel the same way - lots of beginner level content, but not much for people beyond that. So glad you enjoyed this video!
@morapedikhutwane74053 жыл бұрын
Thanks a squillion Joe! 👊🏽 This video is very informative, helpful and enjoyable 😊
@JoeKarlsson3 жыл бұрын
This is my favorite comment :D
@epacke4 жыл бұрын
Excellent presentation, it served super well as a foundation for the design discussions about our NoSQL schema. Although we went to with CouchDB all that you said felt relevant. Instant like!
@dgillies54206 ай бұрын
Love the 1960's-1970's Campagnolo Record bicycle de-exploding at around 25:20 into the video!
@AngeloMiranda19993 жыл бұрын
Great informative video to get started with NoSQL when you come from a relational DB background. Thanks!
@JoeKarlsson3 жыл бұрын
I got you! 🥰
@abdulrashid20233 жыл бұрын
One of the best video about schema design in mongoDB thanks @Joe Karlsson. I subscribed
@jmgomw77874 жыл бұрын
This is a very cool, well explained and fun talk on mongodb. 100% recommeded!
@josemurillo4728 Жыл бұрын
Just one! Love that part. Great vid thanks!
@JoeKarlsson Жыл бұрын
I got you
@ivandrofly5 ай бұрын
43:09 - Good note 48:50 - Ref tutorial
@prajunathunt2 жыл бұрын
The revisions at the end was helpful. Thank you
@JoeKarlsson2 жыл бұрын
YAY
@extremespartan1174 жыл бұрын
Fantastic and straightforward presentation! Thank you sir!
@JoeKarlsson4 жыл бұрын
Oh my gosh! Thank you so much!
@donaldjunior14424 жыл бұрын
Super thanks. Something not spoken about a lot. Modifying schemas structure in production. How can I drop a schema property that I don't need any more? Say username was unique on the user and we don't need that anymore in production. How can I go about that?
@JoeKarlsson4 жыл бұрын
Great question! You will have to write an update query to go through all the appropriate documents and update the schema to your new value.
@donaldjunior14424 жыл бұрын
@@JoeKarlsson thanks for the response. Lost a little. To elaborate e.g. Schema({username: {required: true, unique: true}, firstName:...}) and now we don't need the username anymore. Any operations such as create collection documents without username would error.
@princematthew21452 жыл бұрын
Fantastic Joe. Great Learning. When you talk about embedding example regarding product and parts, you favor parts. But you keep referencing to the size limit of the document. Yes its a problem, But more than that there is a bigger problem of consistency. If you embed a part and If you update the part from a screen, you have inconsistency. When you show the product you will show the old values. I am curious as to why you are not mentioning about inconsistency? I am a newbie in nosql. heavily influence by relational theory. Eager to know your thoughts
@ranylfoumbi46414 жыл бұрын
great! courage bro! it has solved many of my doubts
@JoeKarlsson4 жыл бұрын
YES! That's awesome!
@finalfantasy78203 жыл бұрын
I came from your blog post where this video wasn't shown properly. You might want to fix it, cheers.
@JoeKarlsson3 жыл бұрын
Thanks for the heads up
@quicksketch16174 жыл бұрын
If I want to present the elements from my database like a diagram, exist something like that? If I want to search for data it's not possible if I normalize?
@JoeKarlsson4 жыл бұрын
There are no visual tools that show normalized diagrams on MongoDB data, however, we do have a tool called MongoDB Compass that makes it really easy to view and navigate your data. www.mongodb.com/products/compass
@gmendozamb3 жыл бұрын
I was looking for it too and found this free online tool: mongo.tools
@ubermansch48714 жыл бұрын
you deserve 1 million subscribers
@jjeon98503 жыл бұрын
15:05 Could someone please say the the term he says here? I keep hearing ass complient.
@JoeKarlsson3 жыл бұрын
"ACID compliancy" 🤣
@fernandoventilari8393 жыл бұрын
You really saved me. Thanks a lot!!! Subscribed
@aminatawillane56332 жыл бұрын
Hey there, best video ever on mongoDB schema design I ever seen that far...Thx for it... Since I am building a 5G SA tele medecine project based on mongoDB Atlas and Flutter, may I know please if u' re about to make a class for it? N thx again for that brilliant video...
@blackarrow91003 жыл бұрын
Can WE have 2 schema in the same collection ? Like two type of user user1 and user2 in collection users ???
@JoeKarlsson3 жыл бұрын
Absolutely! Google "Polymorphic Pattern" for more information
@officialgrasptechnology18043 жыл бұрын
Thanks for the vid, now I need someone opinion. Am build a e-commerce store to sell clothing but am wonder if I should put all the product variants in the same document or reference it since as each product have more than one variants. Max properly be arround 10 variants and I only need the data to display on the home page as in "2 images,price and name". What's your guys opinion on this? And what about the query if I only need 2 images,name and retail price on the landing page.
@JoeKarlsson3 жыл бұрын
Depends on how you will use it. Are you planning on showing all variants on your product detail page? If yes, it might be a good idea to embed it since you don't have very many sub variants. Does that help/make sense? 🥰🥰🥰
@polyglotathlete4 жыл бұрын
one of the best explanations, thanks from Bolivia :D
@JoeKarlsson4 жыл бұрын
Oh my gosh! So glad it's useful!
@gompro4 жыл бұрын
Thank you for bringing up a really cool video!
@JoeKarlsson4 жыл бұрын
Yay! So glad you liked it!
@davidemmanuel50572 жыл бұрын
I worked always with mysql so its difficult. Lets say I have this card collection game where a user can have many repeated cards,, I mean I can have the same card multiple times, so I can exchange the card or sell it etc. How can I model my DB to support that functionallity?
@t_kien3 жыл бұрын
I'm newbie and I found this video is amazing, now I can do it.
@code22872 жыл бұрын
Nice resource.....could we get a complete mongodb schema playlist
@knightx94053 жыл бұрын
you are simply the BEST BEST BEST bru!!
@JoeKarlsson3 жыл бұрын
I got chu
@EsHbAnBaHaDuR2 жыл бұрын
Very informative video
@Itsitachine3 жыл бұрын
thanks, man can u say please side the editor's name?
@ajaypratapsingh22224 жыл бұрын
Very well explained
@OfferoC3 жыл бұрын
excellent overview thank you
@JoeKarlsson3 жыл бұрын
I got you
@Lachezariii3 жыл бұрын
If you need referencing why would you even use mongo... The more referencing you do the more you need Postgre :) I am not sure about the speed thing... especially on a huge DB, but nvm, the video was awesome.
@rishavbhowmik81634 жыл бұрын
I think it would be much more logical/safer to store "following" in a document array, then storing "followers"... as follower's array is likely to reach 16MB limit at some point and can not be resolved.
@JoeKarlsson4 жыл бұрын
Totally - as I said in the video, it depends on how your application is structured. Unbounded arrays are always an anti-pattern.
@izaiasaraujogomesdasilva33543 жыл бұрын
One to Few: Rule 1: Favor embedding unless there is a compelling reason not to. Rule 2: Needing to access an object on its own is a compelling reason not to embed it.
@abdullahkhaled61623 жыл бұрын
But why data duplication is not a bad thing?
@manir72513 жыл бұрын
Wow I have used One to Squillions to store logs without actually knowing it😇
@JoeKarlsson3 жыл бұрын
That's amazing - you're a genius MongoDB dev and you didn't even know it :p
@smile52814 жыл бұрын
Minnesota 👍🏾👍🏾👍🏾👋
@JoeKarlsson4 жыл бұрын
Yeah! I'm in Minneapolis!
@hydtechietalks36073 жыл бұрын
YOu can SAVE RECAPs.. now a days!
@JoeKarlsson3 жыл бұрын
Wait - what?
@Grishopping Жыл бұрын
discord????
@christianangelomsulit37593 жыл бұрын
Rule #1 ❤️
@bartekbrakbrak3 жыл бұрын
Why would I listen about technology from an invested party. Mongodb 8s known for mixing marketing and technology. Also mongodb is subtly redefining what schema is. You call lack of schema flexibility (and add silly memes to make this bearable), there is no schema protection in mongo
@JoeKarlsson3 жыл бұрын
Thanks for the feedback 🥰 Did you know MongoDB actually supports schema validation at a database level? docs.mongodb.com/manual/core/schema-validation/
@yanmoenaing713 жыл бұрын
Rule No.1 is my favorite. => Favor embedding unless there is a compelling reason not to.
@axelneumann84433 жыл бұрын
Summary: With MongoDB you have to consider your access patterns not only for indexing but also for schema design. There are three options for child documents: 1. Embedding 2. Array of references in the parent 3. References in the children (foreign key)
@compateur3 жыл бұрын
I'm sorry, but this sounded like a sales pitch :) Understandable since you work for MongoDB. MongoDB has a predecessor, namely XML databases. MongoDB has a lot in common with XML databases. I used to work a lot with XML databases and my experience is that document databases are a * bad * fit for business domain models. You talked about cons and you didn't mention the most important con: update anomalies. But wait a minute. You mentioned this problem and came up with a beautiful solution: a reference. And even better, there is something like unbounded references. I would say, keep evolving and you end up with an SQL database :). In my experience, document databases are great when you store documents as is. For example when you have a message warehouse, or for logging/auditing. XML databases are also used by publishers to store books (DocBook and DITA for example), newspapers etcetera. But using a document database for your business model. That's a bad idea to my opinion. I have the experience to use a very performant XML database as the enterprise database for a company and it had very nasty legal consequences. It was just not the right fit . A relational model is far better. It is also much better to have a schema for you business domain model. I would get very nervous if a developer would store its documents without a schema. No rules, really? Is that a positive thing for your vital business data? Good luck!
@OfficialGOD3 жыл бұрын
I'm using mongol for logging and analytics
@vinfern273 жыл бұрын
When it says no rules. It means you define the rules that fit your business rather than let the rules define your business. you can enforce rules at the db level
@peaps3 жыл бұрын
Does referencing have to use the complicated BSON _id property? Can't we just use another normal property, like, name (presuming it to be unique) ?
@sf29982 ай бұрын
Thank you for this great video. Do you think nosql can completely replace sql? I feel it can if the scheme is done properly...
@JoeKarlsson2 ай бұрын
It depends on the used case, but for a lot of cases noSQL databases work just fine
@dnxsol3 жыл бұрын
Dude, why do you refer to SQL as Legacy... man that is such mongoDB propogranda... you make it sounds like no body still uses SQL... other than tham good vid
@BrandonClapp4 жыл бұрын
You better hope that kitty doesn't go to the bathroom 60,000 times in 1 day or else you might hit that 16mb limit... amongst having other problems.
@JoeKarlsson4 жыл бұрын
This was a risk I was willing to take ;) I'd probably be bringing my cat into the vet instead of worrying about my MDB data if this happened :P
@karamjeetsingh76374 жыл бұрын
This was super helpful, Cleared many doubts I had. Thank you very much!
@JoeKarlsson4 жыл бұрын
That's amazing! Thank you so much for watching! :D
@joaquindelprado1334 жыл бұрын
this is a really nice video!! thanks a lot for sharing your knowledge it's help me a lot
@JoeKarlsson4 жыл бұрын
Yay! Thank you so much! I'm so glad that it's useful :D
@PuzzlingQuestions4 жыл бұрын
This was really good. One thing that made me laugh is in the begining you stressed that there are no rules and then later you have "Rule 1: favour embedding" haha I just thought that was funny. Thanks for the presentation, it was helpful!
@JoeKarlsson4 жыл бұрын
LOL - you're totally right. I totally missed the irony! hahaha! :D
@attilathehun15614 жыл бұрын
Nice Video , Every thing is crystal clear you saved my lots of time , i am new to mongoDB from MySql background keep it up.
@JoeKarlsson4 жыл бұрын
This is the best compliment! Thank you so much!
@soyebganja86324 жыл бұрын
Many thanks:)
@arnaudtisset4 жыл бұрын
Professional SQL developer here Actually the first part of your video is a little misleading, we do design sql databases with the queries in mind and We denormalize when necessary.
@JoeKarlsson4 жыл бұрын
You're right - It's not an antipattern in SQL to denormalize for performance reasons - thank you for clarifying. :D
@bestblackpeoplevine79073 жыл бұрын
Thank you
@bemineni3 жыл бұрын
May be it should have been called Squillions to one
@bornash68094 жыл бұрын
This was super helpful, Cleared many doubts I had. Thank you very much!
@JoeKarlsson4 жыл бұрын
So glad that it was helpful!
@Adam-uu8dc2 жыл бұрын
Love the office meme. Great tutorial!
@distributed-systems3 жыл бұрын
12:32 Embedding 17:10 Referencing
@Dxpress_3 жыл бұрын
Seems like a good approach to embedding VS referencing would be to consider if the data should be able to exist independently. For instance, if you have a user profile schema, it could look something like this: { username: "someName", contactInfo: { email: "someEmail@email.com", phoneNumber: "123456789" }, address: { street: "123 Main St." city: "New York", country: "USA" } } You could then ask yourself, "is there ever going to be a need to have a contactInfo or address object exist independently of a user profile?" If not, go ahead and embed them. The only way for these embedded objects to change is for the user to change their profile information, and nowhere else. On the other hand, maybe you have a case in your application where you want users to only select from a preset list of addresses to add to their profile. In this case, addresses _can_ exist independently of a user profile, so you'd want to create a collection of addresses, and have user profiles reference them instead.
@biomedicaltechworld-btw84473 жыл бұрын
Thanks for making such a comprehensive video for us. Stay Blessed.
@JoeKarlsson3 жыл бұрын
I got you! 🥰
@biomedicaltechworld-btw84473 жыл бұрын
@@JoeKarlsson started watching MongoDB University course after this video. Your company must be proud of you. 👌🧡
@lazareric Жыл бұрын
I love you man, not many people talking about mongo, with proper knowledge of it. Good on you. An interesting question maybe, client wanted an architecture where each A collection item has many B collection items attached to it by reference, BUT querying A collection requires searching based on B collection items' properties, it was super slow, whenever I queried (50m+ documents), a collection based on properties of a different collection (so match, lookup, and the match on the lookuped documents), the query was super slow. The weird part is lookup was relatively fast even, but than the match on the lookedup documents' properties was weirdly very, very slow, any ideas why that happen? It's weird as I imagine once lookup is done, each document gets that embedded and then goes into the next stage (match) in this case, so why was match so slow, as it was supposed to match based on the already available properties embedded in the document in that stage with data in the stage (or maybe I don't understand, and it doesn't really work like that what I explained), it didn't have to use an index or do a collection scan, literally just filter documents in the stage, that's the only mind boggling thing in mongo that i don't get, everything else I love
@idontwhy31323 жыл бұрын
welp. time to flatten that recursively embedded doc
@JoeKarlsson3 жыл бұрын
hahahaha - sounds like fun :P
@BiharGaurav2 жыл бұрын
Instead of referencing can I keep just list of id of another document and just query those specific ids? I mean what will be the performance in that case?
@alirasheedmd3 жыл бұрын
Solved all my doubts man since morning was searching for embedding design. Thanks a lot 👍
@JoeKarlsson3 жыл бұрын
That's amazing! Thank you for sharing!
@silvesterwali65654 жыл бұрын
Great job
@JoeKarlsson4 жыл бұрын
Thank you so much!
@silvesterwali65654 жыл бұрын
Keep going...Mike..
@WeMakeShorts212 жыл бұрын
what if the cat goes in the bathroom a squillion time?!
@JoeKarlsson2 жыл бұрын
LOL
@asdfasdfasdfasdf2193 жыл бұрын
Best f*cking video I found so far. Liked and shared in LinkedIn. It could be good to add a sample for rule #2.
@gurmukhsingh2026 Жыл бұрын
This is the best into for MongoDB. thanks a lot!
@JoeKarlsson Жыл бұрын
I got you
@arrafiialfa46093 жыл бұрын
hi I got a question would it be better to keep reference on both document in one to many scenario or would it be better to just keep the reference on the one document that holds many docs ?
@billb56023 жыл бұрын
I didn't know Dane Cook knew how to code
@JoeKarlsson3 жыл бұрын
It's true!
@elliot74262 жыл бұрын
Sir, thank you for this. :)
@JoeKarlsson2 жыл бұрын
You're welcome, friend!
@alejandrocr92934 жыл бұрын
Thank you
@JoeKarlsson4 жыл бұрын
You're welcome :D
@Cons29118 ай бұрын
I’m early into the video but I just want to say thank you. I’m new to this, so I’m trying to understand esp coming from relational
@hekh3k4 жыл бұрын
Awesome 👍🏻
@JoeKarlsson4 жыл бұрын
Yay!
@HenIsTheMan3 жыл бұрын
This vid is dope!
@JoeKarlsson3 жыл бұрын
YAY! THANK YOU
@rickvian3 жыл бұрын
Hi Joe, can i apply your code to existing account?
@JoeKarlsson3 жыл бұрын
Yeah - it should still work :D
@rickvian3 жыл бұрын
@@JoeKarlsson thanks! btw i have question regarding $date and $numLong, what does that mean?
@umeshwar214 жыл бұрын
great , I found it is very help full video to start project with schema design
@JoeKarlsson4 жыл бұрын
I got chu ;)
@ayushkushwaha1714 жыл бұрын
Thanks for the video Joe
@JoeKarlsson4 жыл бұрын
Oh my gosh! I am so glad you enjoyed it!
@YoloMonstaaa3 жыл бұрын
You're an amazing teacher. Thank you.
@JoeKarlsson3 жыл бұрын
Thank you! 🥺🥰👑
@andrew-ni1lb3 жыл бұрын
Dude, thanks, I have enjoyed your explanations!
@Alikus784 жыл бұрын
Thank you very much for the presentation! So if data I am embedding instead of referencing needs to have its own unique ID. I am used to getting these IDs for free in SQL world... is there something Mongo DB had for this or I am on my own with generating and keeping track of these IDs? Thanks!!
@JoeKarlsson4 жыл бұрын
By default, MongoDB creates a unique UUID under the _id key on every single document you create. You get them for free with MongoDB too! :)
@alikkasman98534 жыл бұрын
@@JoeKarlsson I was taking about adding an ID to a subitem inside document (embedded structure) that doesn't get an ID by default. Looks like I can generate this ID in application by doing something like BSON::ObjectId.new and it will be unique to the DB
@JoeKarlsson4 жыл бұрын
@@alikkasman9853 Yes! You are exactly right :)
@aniketsao3 жыл бұрын
Awesome video. thanks for creating and sharing it. I'm new to the NoSQL databases, is there a way to test the performance of embedding vs referencing ? given the unknowns of how an application would evolve, its hard to stick to one design. have you encountered any scenarios where over time the design needed to be changed from embedded to referencing.
@JoeKarlsson3 жыл бұрын
The best way to determine which schema is "best" is to run experiments by running queries with different schemas and using the built-in MongoDB Performance Advisor to determine which one is fastest. And yes, I have seen people needing to shift schema's overtime all the time. It's really common for web apps to have features and requirements shift over time. So, an old schema that worked great, no longer fits new requirements. It's not a problem to update your schema.
@niamatullah65882 жыл бұрын
can you record a video on schema concept during get or update API's
@tgerambio Жыл бұрын
This is beautifully explained. Thank you sir!
@andreornelas3 жыл бұрын
Really enjoyed your video. Was kinda funny when you said MongoDB has no Rules but then we have a section with Rules. hehe. Altough they are very helpful to keep in mind. Thanks for the great content!
@JoeKarlsson3 жыл бұрын
hahaha - lol - I def lied there! :P
@anuragtiwari30324 жыл бұрын
Thnx a lot man , this answered so many of my doubts. Deserves 10 million views, but we all know the world 😉
@JoeKarlsson4 жыл бұрын
🙌
@victorkingma43717 ай бұрын
Excelent tutorial, gave me a entire panoram of mongodb
@edwardmike7523 Жыл бұрын
Thanks for the explanations, very clear .☺
@soumabratabhattacharya33754 жыл бұрын
Awesome tutorial. Thank you very much!
@louierichardson1233 жыл бұрын
I am creating a bug tracker web app and this has answered my questions about how I should structure my many to many relationship, so thank you!
@JoeKarlsson2 жыл бұрын
That's so cool! Can you send me the code? I would love to check out what you're working on!
@macadameane3 жыл бұрын
Google probably has a dashboard for how often I use the bathroom too.