Week 22

This week we started learning about MongoDB, which feels very different from the SQL databases we had been using before. Up until now, we mostly worked with MySQL, where data is organized into tables with rows, columns, and relationships. In contrast, MongoDB stores data as documents inside collections, using a structure similar to JSON. At first, it was a little strange not having to create tables or define strict schemas, but it also made sense once I saw how flexible it can be.

One thing I found interesting is that MongoDB doesn’t require a fixed structure for the data. You can have documents with different fields in the same collection, which would not be possible in MySQL. This flexibility could be really helpful when building applications where the type of information might change or grow over time. On the other hand, MySQL forces you to define everything in advance, which helps maintain order and consistency when dealing with large, structured datasets.

Both databases serve a similar purpose — storing and retrieving data — but they do it in different ways. MySQL is great for handling data that needs clear relationships, like customers and orders in a store. MongoDB seems better for data that’s more dynamic, like user profiles or product catalogs that may have varying attributes.

If I had to choose between the two, I would probably use MySQL for projects where accuracy, constraints, and relationships are important, such as accounting or inventory systems. For projects that need to handle lots of changing or unstructured data, like social media apps or analytics platforms, I’d go with MongoDB. Overall, learning about MongoDB this week helped me appreciate how different database models can be used for different needs, and it gave me a broader perspective on how data is managed in modern applications.