CST 363 - Week 7 - MongoDB (sounds like Mango)
Coming from MySQL, the biggest difference with MongoDB is how it stores data. In MySQL, I had to carefully plan out my tables and columns ahead of time, and every row had to follow that exact structure. With MongoDB, it feels like I'm working with flexible JSON documents instead of rigid tables. One document can have different fields than the next one and the same collection, which is a huge change. It seems like you can just start building without having everything perfectly mapped out, which is both cool and a little scary. I imagine it would be easy to build yourself into walls.
Even though they feel totally different, I'm seeing some similarities that make sense. Every document in MongoDB gets a unique _id, which feels just like the primary key I'm used to in MySQL for identifying a specific row. They both also use indexes to speed up searches, so the basic idea of making queries fast is the same. The main challenge is learning how to ask for data. I'm used to writing SQL commands like SELECT * FROM users, but in MongoDB, I have to write a query that looks like a JSON object to find what I need.
I think I'm starting to understand when I'd use each one. If I were building an application where data integrity is super important and the structure is fixed, like for an e-commerce site's orders, I'd definitely stick with MySQL because it’s so strict and reliable. This would be similar to if I were building something that had massive amounts of data, and needed fast reliable methods of query / indexing.
But for a project where the data might be unpredictable or change a lot, like a blog or a content management system, MongoDB's flexibility seems like it would make development so much faster and easier. It also feels like a better choice to get something off the ground quickly. Like at the start of a project where you can't map 100% of the data needs.
Comments
Post a Comment