✅ Sign-up for a free cluster at: mdb.link/free-QAqK-R9HUhc ✅ Get help on our Community Forums: mdb.link/community-QAqK-R9HUhc
@paracha32 жыл бұрын
Not sure if i am fan of this delivery style but he was getting the point across.
@joshuapapa7637 Жыл бұрын
I gotta agree with you, I literally came here not knowing a thing and I almost feel like I can create a project out of scratch after watching this.
@chauphan40743 жыл бұрын
Rule 1: embed unless there is a compelling reason not to Rule 2: avoid JOINS if they can be avoided Rule 3: array should never grow without bound Rule 4: an object should not be embedded if it needs to be accessed individually
@jmanpolo56112 жыл бұрын
Coming from a SQL mindset to MongoDB is an interesting experience, but also kinda freeing in a way.. thanks for making this video!
@BobMacNeal3 жыл бұрын
Good job explaining/confirming my loosely established notions about how to design a NoSQL database. Thanks Joe. MongoDB is a low-resistance (easy to use) database that’s become my go-to data store for standing up products.
@jbsinluenam Жыл бұрын
I have never knew MondoDb schema design can be this entertaining. Thank you, Joe.
@picklebrownie Жыл бұрын
So, for many-to-many relationships, Joe suggests to store the relationship data in BOTH tables (very unlike SQL dbs where we avoid redundancy). This helped me resolve a quarrel with myself on the db schema for my first MongoDB Atlas Collections. Thanks Joe
@maxpayenvenic60292 жыл бұрын
Joe is kind of person that make learning fun
@VoxyDev3 жыл бұрын
MongoDB needs Joe, he's so good at explaining things
@king-manu27583 жыл бұрын
Im a total noob at programming and Mongo db but after watching this I think I'm at least on the right track
@JoeKarlsson3 жыл бұрын
That's awesome! I'm so glad it was helpful!
@MongoDB3 жыл бұрын
Yay! That great that it was helpful!
@murph13292 жыл бұрын
Things people really need to consider before moving everything to MongoDB. It isn't a relational database management system. Saying MongoDB is better than any RDBMS without first specifying the data shows a real lack of knowledge. Key constraints don't exists in MongoDB. There are no referential integrity checks. We use MongoDB for blob storage and store the MongoDB keys in SQL Server. It's great for that but I would never outright replace a normalized SQL Server or a MySQL RDBMS instance with MongoDB. Maybe a lot of people see MongoDB as being better because they don't want to worry about optimizing indexes and execution plans, and they see the "read" performance gains...but that comes at a cost of data integrity. It's a schemaless structure which means consistency doesn't exist. It will eat anything you feed it which can be dangerous. Think about what happens over time as you add/remove properties from your JSON or add/remove reference data based on changing business rules. Think about what that conversion would look like in MongoDB compared to a RDBMS instance. Using the example in this video what if there was a business rule that allowed someone to remove a profession (physical or logical) from all users. Ask yourself what that would look like in MongoDB vs a Relational Database. I know I sound pretty critical of MongoDB but I don't mean to. We use it and it works well for our needs but it's not a replacement for RDBMS. More of a supplement. NoSQL shines in write-once-read-many scenarios.
@oberoioffice1103 Жыл бұрын
Explains the conept very well...thanks
@paulafarrugia33933 жыл бұрын
Great tutorial - would be great to have a video tutorial on how to actually implement the relationship types in realm!
@MongoDB3 жыл бұрын
Great suggestion!
@paulafarrugia33933 жыл бұрын
@@MongoDB Is this something that you think you will release soon? I'm having trouble with relationships when using Realm and GraphQL and noone on the MongoDB community is helping.
@mirlamontano6640 Жыл бұрын
agree
@real23lions9 ай бұрын
Excellent video. This was my main concern when attempting a scheduler.
@underwoodmartin3 жыл бұрын
Great firehose video for those of us that have spent many many years in a relational world. I have did some entry level testing with MongoDB and love the concept. The "schema" is the most challenging part. Awesome video!
@JoeKarlsson3 жыл бұрын
Oh my gosh - Thanks for sharing Martin! Are there any topics you think MongoDB devs should know about?
@MongoDB3 жыл бұрын
Thanks for sharing!
@underwoodmartin3 жыл бұрын
@@JoeKarlsson MongoDB has always been very intriguing to me with the BSON based storage. I would love a series on taking a case study of an OLTP based system and converting to MongoDB. Highlighing the many decision and concerning aspects along the way. Thank you for inquiring and looking forward to finding time to watch more.
@AnNguyen-px6lg2 жыл бұрын
I love the style of this video so much. It makes learning tech so much more fun compare to other monotone tech videos.
@RN-er7mz3 жыл бұрын
Great tutorial, short and straight to the point
@MongoDB3 жыл бұрын
Thank you!
@elonhung24303 жыл бұрын
Thanks Joe! That is gold. Very clear and so fun to watch!
@SaudBako3 жыл бұрын
Isn't the array "tasks" at 8:45 unbounded, which violates Rule 3?
@matonolo3 жыл бұрын
Yeah it does, and I can't think of a way to solve the 60mb per document limit problem... Anyone know how to solve it?
@sjacobsen3 жыл бұрын
Just depends on the application. Technically: yes. Are users REALLY going to have an unlimited amount of todo tasks that will create document size problems: no. If you're worried about malicious activity doing this to kill your site then setup some business logic to keep a user from creating a billion tasks.
@sleeker165 Жыл бұрын
Excellent demo thanks 👍
@laodemuhammadalfatih76633 жыл бұрын
Omg. I really love about how Joe explain the all of these schema design. Never feel exciting like this when learning new concept. Thanks Joe ❤️.
@davishek72 жыл бұрын
Just read the same blog on the mongodb site. Both are great for beginners.
@coderblog4485 Жыл бұрын
great work Joe!. In fact, it is very interesting to watch your videos about MongoDB, but I am confused about one thing🧐🤨
@enemy537 Жыл бұрын
I loved your video Joe. Fantastic. You are such a character! hahaha
@learn9475 Жыл бұрын
I can see the passion video quality is awesome upto the mark not just learnt but njyed learning from you thanks
@deathdefier45 Жыл бұрын
You're the best Joe, I had a filthy schema structure until I saw this video.
@atikanajla Жыл бұрын
I need more video from you Joe
@gt810034 Жыл бұрын
Excellent explanation. Thanks Joe
@niknacknutthapon43732 жыл бұрын
i'm new on your VDO, Love it ! Great tutorial. you make learning super fun
@dixxixio2 жыл бұрын
This helps a lot! Thanks Joe!
@vaibhav388 Жыл бұрын
Thank you . that's what i was looking for ;)
@SomeKindaWhale2 жыл бұрын
Grok! Nice 😊 thanks! This was a super informative and fun video explainer
@philyeo3 жыл бұрын
Great explanation. Just what I was looking for.
@fernandonogueira22918 ай бұрын
This video is absolutely histerical! haha Amazing, Mongo!
@unnoticedspacegoat8537 Жыл бұрын
love the energy
@zulmianah2 жыл бұрын
thank you, really helping
@sneakykk Жыл бұрын
he is so full of energy. bless him!!!
@picklebrownie Жыл бұрын
Oh wow, super clever way to handle squillions of data relationships 💯
@dubey_ji Жыл бұрын
okay that Pam's bit was funny
@pazuso2 жыл бұрын
My app shows a profile page of a student with a list of classes she's enrolled in. Classic Student/Class/Enrolment tables in SQL. In Mongo I would want to just embed everything in 1 document. What if I change the name of a class, or a student drops a class previously enrolled? How do I do this WITHOUT joins? "Throw away" the document (delete) and just make a new one (like a piece of physical paper) with the updated stuff?
@DarkzarichV28 ай бұрын
I don't quite get why with many-to-many relationship we store tasks within user model as the rule way when we can technically query tasks that $in a user we want to get. It would also make updates\deletes harder because now if we have to remove a task we need to delete elements in both arrays: user.tasks array and owners array of the task. I'm not saying it's bad per se it really depends on what app we have: having tasks inside user model would certainly make it faster for users to see what tasks they got. Anyway if I remember correctly this is what is called denormalization: we introduce a bit overhead in the data to make updating and removing slower but reading faster in certain particular cases. Denormalization is a bit harder than just "do like this" thing
@ljbrown2383 жыл бұрын
VERY helpful!
@michaelshea48343 жыл бұрын
I am not sure why, but for some reason it looks like you are filming inside a bar before it opens. Weird.
@zedrem98765432103 жыл бұрын
What's the best way to model a one to many relationship within a single collection. E.g. users following users? I always use a followers array on the user document that stores other user IDs, but it feels clanky (unbounded array?)
@hope-ag2 жыл бұрын
This scenario resembles a many-to-many relationship (each user can follow and be followed by many users, if I'm not mistaken). Depending on the scale of the application, an array of sub documents would do just fine. For larger applications, you could probably have a "Followings" collection, which stores, for example {user: $oid, followedBy: $oid}. This collection can easily be queried for whichever user's followers you'd want to find
@sumer4203 жыл бұрын
iam new to mongodb .and i want to know how what is best practices and what is not best but optimum for my needs 1) get all the data and sort and filter client side (i know this is bad) 2) filter data on mongo atlas and then sort client side (dose it make any difference to save resource on server ) 3) filter and sort on server and just show data on client what should i do and what are best practices. like i get a list of documents from server with embedded objects. 1) should i use project and remove embedded objects i dont need.( does this use more server resource) 2) or i get all the embedded objects and hide them with client side logic
@labydamarocamara58743 жыл бұрын
thank you for this video it is so amazing, really I like it.
@MongoDB3 жыл бұрын
We're so glad that you enjoyed it!
@codingcambodia3 жыл бұрын
I have a collection called "hospitalization" that stores two collections ids a hospital_Id and a patient_Id. My question is I want to query hospitalization collection and search by keyword of field of hospital collection of hospital collection. how can I do so?
@BelieveInPeople1212 жыл бұрын
is joins in mongodb slower than sql server? because if I use objectids, I will always need joins.
@funksoul1234563 жыл бұрын
Thank you for sharing. Would you also provide the link for anti-pattern design?
@MongoDB3 жыл бұрын
Of course! kzfaq.info/get/bejne/bqmKppBhztqdomg.html
@dancruz7845 Жыл бұрын
If an array can not grow without bound how to we manage something like a users posts? We obviously wouldn't want to limit a users posts so how do you work around that?
@williamhorn3638 ай бұрын
I'm guessing you would just create a new document containing the post data, and attach the user's ID somewhere in there. Then you just query posts for a user id whenever you want to retrieve all posts from a user.
@juanbovier7458 Жыл бұрын
💯
@jdragon81842 жыл бұрын
Can anyone please please help me with how can I make combination of 2 field values unique , should i use a pre save or method to implement it or mongo has something for it 1 i want to have unique anime name for a particular user , so i use a createdBY userid to identify it but I cannt make anime title unique
@Dannyboyjr Жыл бұрын
dude is awesome
@rohannnsingh843 жыл бұрын
That's what i waz looking as i am strtng to swtch from sql to mongo but after viewing this i have a ques ...what if data is in millions or in tonnes let suppose the user has 10k cars just assume then what happens?? What about efficiency then , will it work as same speed ????
@MongoDB3 жыл бұрын
Well - it depends. The only way to know is to run a test on your dataset to see how well it will perform. However, it's not an anti-pattern to do this in MongoDB. Another question to ask is "How often will this be done?" If it's rare, it's usually not an issue, if it's often, you might want to change your schema. The only thing that matters is designing a schema that meets the needs of your unique application. Hope that helps!
@magellan124 Жыл бұрын
What is going on with that painting back there?
@kevinandeleven3 жыл бұрын
What of squilions to squilions relationships? Something like users and post-likes.... A user can like a squilion posts and a post can have a squilion users that like it
@snake38373 жыл бұрын
Maybe just 3rd collection containing user and post id.
@jungtinnumbertwo43233 жыл бұрын
Love the content
@liquidcode17042 жыл бұрын
SQL => business/enterprise 'storage' MongoDB => application state !!! =]
@dkin8603 жыл бұрын
w00t
@MongoDB3 жыл бұрын
w00t!
@dataisbeauty55123 жыл бұрын
1 st comments
@MongoDB3 жыл бұрын
Nice!
@moosegoose1282 Жыл бұрын
Unwatchable. Just get to the point.
@ZalexMusic3 жыл бұрын
You are extremely likeable
@picklebrownie Жыл бұрын
NO RULES 🤯 NO ALGORITHM 🤯 NO PROCESS 🤯
@picklebrownie Жыл бұрын
Woohoo! There are rules! It's not total anarchy 😂
@TheNamesJT2 жыл бұрын
I don't find this video helpful sorry, wish you would of shown actual code using schema and models and how to connect two schemas together. This video is just saying we have to do this and do that but you never show us code wise. VERY HELPFUL
@krishnandusarkar3 жыл бұрын
Thanks for the explanation. Honestly, too much transition effects and fast speaking actually affecting the concentration.
@MongoDB3 жыл бұрын
Sorry to hear that! Thanks for watching 🥰
@MultiMunding8 ай бұрын
Yeah but what about many to squillions or squillions to squillions? Back to joins? 😆
@picklebrownie Жыл бұрын
One to squillions 😂
@picklebrownie Жыл бұрын
Squillions is an unspecified massive number. I for real thought you made it up for a moment there 😂