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
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
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.
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.
@@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.
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.
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!
@@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.
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?
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?
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.
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?)
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
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?
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
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
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
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 ????
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!
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
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
✅ Sign-up for a free cluster at: mdb.link/free-QAqK-R9HUhc
✅ Get help on our Community Forums: mdb.link/community-QAqK-R9HUhc
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
Not sure if i am fan of this delivery style but he was getting the point across.
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.
Coming from a SQL mindset to MongoDB is an interesting experience, but also kinda freeing in a way.. thanks for making this video!
MongoDB needs Joe, he's so good at explaining things
I have never knew MondoDb schema design can be this entertaining. Thank you, Joe.
Excellent video. This was my main concern when attempting a scheduler.
Im a total noob at programming and Mongo db but after watching this I think I'm at least on the right track
That's awesome! I'm so glad it was helpful!
Yay! That great that it was helpful!
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
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.
Explains the conept very well...thanks
Joe is kind of person that make learning fun
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.
I love the style of this video so much. It makes learning tech so much more fun compare to other monotone tech videos.
I loved your video Joe. Fantastic. You are such a character! hahaha
Great tutorial, short and straight to the point
Thank you!
Thanks Joe! That is gold. Very clear and so fun to watch!
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 ❤️.
Great tutorial - would be great to have a video tutorial on how to actually implement the relationship types in realm!
Great suggestion!
@@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.
agree
I can see the passion
video quality is awesome
upto the mark
not just learnt but njyed learning from you
thanks
Just read the same blog on the mongodb site. Both are great for beginners.
Isn't the array "tasks" at 8:45 unbounded, which violates Rule 3?
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?
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.
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!
Oh my gosh - Thanks for sharing Martin! Are there any topics you think MongoDB devs should know about?
Thanks for sharing!
@@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.
You're the best Joe, I had a filthy schema structure until I saw this video.
Excellent demo thanks 👍
I need more video from you Joe
Excellent explanation. Thanks Joe
great work Joe!. In fact, it is very interesting to watch your videos about MongoDB, but I am confused about one thing🧐🤨
Thank you . that's what i was looking for ;)
i'm new on your VDO, Love it ! Great tutorial. you make learning super fun
This helps a lot! Thanks Joe!
he is so full of energy. bless him!!!
Grok! Nice 😊 thanks! This was a super informative and fun video explainer
This video is absolutely histerical! haha Amazing, Mongo!
Oh wow, super clever way to handle squillions of data relationships 💯
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?
Great explanation. Just what I was looking for.
love the energy
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?
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.
thank you, really helping
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?)
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
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?
okay that Pam's bit was funny
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
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?
Of course! ua-cam.com/video/8CZs-0it9r4/v-deo.html
thank you for this video it is so amazing, really I like it.
We're so glad that you enjoyed it!
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
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
What is going on with that painting back there?
VERY helpful!
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 ????
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!
dude is awesome
SQL => business/enterprise 'storage'
MongoDB => application state !!! =]
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
Maybe just 3rd collection containing user and post id.
Unwatchable. Just get to the point.
NO RULES 🤯
NO ALGORITHM 🤯
NO PROCESS 🤯
Woohoo! There are rules! It's not total anarchy 😂
💯
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.
Sorry to hear that! Thanks for watching 🥰
Love the content
Yeah but what about many to squillions or squillions to squillions? Back to joins? 😆
You are extremely likeable
1 st comments
Nice!
w00t
w00t!
I hate this background music I don’t why😂
One to squillions 😂
Squillions is an unspecified massive number. I for real thought you made it up for a moment there 😂