Week 23

Throughout this database course, I learned several valuable concepts and skills, but the three most important ones for me were integrating databases with Java, learning SQL, and understanding NoSQL with MongoDB.

First, the integration between Java and SQL helped me understand how real-world applications connect to databases. By creating repositories, writing queries, and using JDBC connections, I learned how data can flow between a program and a database, which is essential for any backend or full-stack developer. It also taught me how to handle exceptions, maintain data consistency, and structure code that interacts efficiently with database systems.

Second, learning the SQL language itself was a fundamental part of this course. I learned how to design relational databases, define relationships between tables, and use queries such as SELECT, JOIN, and GROUP BY to extract meaningful information. Understanding normalization, primary and foreign keys, and integrity constraints gave me a solid foundation in data management and design principles that apply to almost any system that handles structured data.

Finally, exploring NoSQL with MongoDB expanded my perspective on database systems. I discovered how flexible document-based storage can be compared to the rigid structure of relational databases. Learning how to use collections, documents, and queries in MongoDB showed me how NoSQL can be ideal for projects that need scalability and rapid development. This contrast between SQL and NoSQL helped me appreciate the strengths and trade-offs of both approaches and how to decide which one fits best depending on the project’s needs.

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.

Week 21

This week we learned how to connect a database to a Java program that works as a web page. It was really interesting to see how information stored in MySQL could be displayed, added, or updated directly through the program. At first, it was a little confusing to understand how the Java controller and the database communicate, but after testing the connection and seeing it work, everything started to make more sense.

I think this type of project is very useful because it shows how websites and applications handle real data behind the scenes. For example, when we register a new patient or update their information, the data is immediately stored in the database and can later be retrieved or edited. It felt like building a small real-world system, not just working with SQL commands. That made the learning experience more practical and interesting.

Even though in the future we might not use Java for building websites—most likely we’ll use languages like Python, JavaScript, or PHP—the concept we learned this week will still be very helpful. Understanding how the backend connects to a database helps us know what’s possible when creating dynamic websites. Now I feel more confident that I could apply this knowledge in future projects or even in a professional environment.

Week 20

This week I read about “slow indexes” on Use the Index, Luke, and it helped clear up a common misconception. I always thought that if a query uses an index, it should automatically run faster. But the author explains that even indexed queries can be slow depending on how the database has to look up the data.

A slow index happens not because the index is broken, but because of how much work the database still has to do. First, it finds the right spot in the index tree, but then it may need to follow a long chain of leaf nodes if there are multiple matches. After that, it has to go back to the main table to fetch the actual rows, which might be scattered in different places. All those extra reads can make the query take longer.

The site also describes three kinds of scans: an INDEX UNIQUE SCAN, which is the fastest because it finds only one match; an INDEX RANGE SCAN, which has to go through several entries; and TABLE ACCESS BY INDEX ROWID, which retrieves the full data from the table. When a query has to do many range scans and table lookups, it can become slow even though it’s technically using an index.

What stood out to me is that a “slow index” isn’t really a problem with the index itself, it’s about how the query interacts with the data. It’s a good reminder that optimizing performance isn’t just about adding indexes, but also about writing smarter queries and understanding how the database reads information.