✅ Sign-up for a free cluster at: mdb.link/free-QAqK-R9HUhc ✅ Get help on our Community Forums: mdb.link/community-QAqK-R9HUhc

Not sure if i am fan of this delivery style but he was getting the point across.

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

Coming from a SQL mindset to MongoDB is an interesting experience, but also kinda freeing in a way.. thanks for making this video!

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.

I have never knew MondoDb schema design can be this entertaining. Thank you, Joe.

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

Joe is kind of person that make learning fun

MongoDB needs Joe, he's so good at explaining things

Im a total noob at programming and Mongo db but after watching this I think I'm at least on the right track

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.

Explains the conept very well...thanks

Great tutorial - would be great to have a video tutorial on how to actually implement the relationship types in realm!

Excellent video. This was my main concern when attempting a scheduler.

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!

I love the style of this video so much. It makes learning tech so much more fun compare to other monotone tech videos.

Great tutorial, short and straight to the point

Thanks Joe! That is gold. Very clear and so fun to watch!

Isn't the array "tasks" at 8:45 unbounded, which violates Rule 3?

Excellent demo thanks 👍

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 ❤️.

Just read the same blog on the mongodb site. Both are great for beginners.

great work Joe!. In fact, it is very interesting to watch your videos about MongoDB, but I am confused about one thing🧐🤨

I loved your video Joe. Fantastic. You are such a character! hahaha

I can see the passion video quality is awesome upto the mark not just learnt but njyed learning from you thanks

You're the best Joe, I had a filthy schema structure until I saw this video.

I need more video from you Joe

Excellent explanation. Thanks Joe

i'm new on your VDO, Love it ! Great tutorial. you make learning super fun

This helps a lot! Thanks Joe!

Thank you . that's what i was looking for ;)

Grok! Nice 😊 thanks! This was a super informative and fun video explainer

Great explanation. Just what I was looking for.

This video is absolutely histerical! haha Amazing, Mongo!

love the energy

thank you, really helping

he is so full of energy. bless him!!!

Oh wow, super clever way to handle squillions of data relationships 💯

okay that Pam's bit was funny

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?

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

VERY helpful!

I am not sure why, but for some reason it looks like you are filming inside a bar before it opens. Weird.

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?)

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

thank you for this video it is so amazing, really I like it.

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?

is joins in mongodb slower than sql server? because if I use objectids, I will always need joins.

Thank you for sharing. Would you also provide the link for anti-pattern design?

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?

💯

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

dude is awesome

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 ????

What is going on with that painting back there?

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

Love the content

SQL => business/enterprise 'storage' MongoDB => application state !!! =]

w00t

1 st comments

Unwatchable. Just get to the point.

You are extremely likeable

NO RULES 🤯 NO ALGORITHM 🤯 NO PROCESS 🤯

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

Thanks for the explanation. Honestly, too much transition effects and fast speaking actually affecting the concentration.

Yeah but what about many to squillions or squillions to squillions? Back to joins? 😆

One to squillions 😂

I hate this background music I don’t why😂