Posts

Showing posts from October, 2024
Starting my journey in CST334 Operating systems. This week I focused on learning the basics of shell scripting in Linux using Ubuntu in VirtualBox. I learned essential commands like ls, wc, and whoami to gather and display system information within a script. Through this process I learned how to handle user input and use conditional statements to control the program flow. I also practiced using loops to repeat calculations, specifically finding the area of a rectangle and a circle based on user input. I ran into an issue of extended decimal places which in turn pushed me to learn formatted outputs with specific 2 place decimal places. This practice deepened my understanding of Unix command-line tools, scripting logic, and how to create interactive programs using bash.
CST 363 Introduction to databases Introduced a lot, but here are a few things that really stand out. Understanding how to design and normalize databases was a game-changer,  it helped me see how to organize data efficiently and avoid redundancy. Learning about SQL transactions and managing concurrency showed me how to keep data safe and consistent when multiple users are involved and accessing th data under diffrent circumstances which felt very practical for real-world use. And finally, getting hands-on with the Java Spring framework and building web apps really brought everything together for me. I now feel confident about creating full applications that connect to databases and solve real problems. Overall, it’s been a challenging journey but rewarding in the end.
I was looking forward to learning about the differences between SQL and NoSQL databases, and comparing MongoDB with MySQL has really helped. MongoDB being a NoSQL database is all about flexibility, it stores data in JSON-like documents which makes it perfect for handling changing or unstructured data. It's ideal for apps that need to scale quickly or manage large amounts of differing data For example, real-time analytics or social media platforms. MySQL as a relational database, keeps data organized in structured tables with well-defined relationships making it perfect for systems that require strict consistency and reliability. An example being financial applications or e-commerce platforms. Both databases have powerful features like indexing and querying but the choice between them really comes down to whether you need the flexibility and scalability of MongoDB. Or you are looking for a more structured transaction-secure nature of MySQL.
This week, I gained practical experience with SQL and JDBC in Java by building a program that connects to a MySQL database. I learned how to set up and manage database connections, use prepared statements to insert and retrieve data, and handle transactions effectively by committing or rolling back changes when necessary. I also got better at managing exceptions and ensuring that resources like connections are closed to avoid memory leaks. Beyond the technical aspects this week highlighted the value of teamwork. My group and I worked together to divide the tasks, each of us focused on different parts of the code. This approach made the whole process much more efficient and organized. It not only helped us complete the project faster but also improved the quality of our work. Collaborating like this really showed me how important good planning and communication are when working on a team.
This week I got a deeper look into why indexes, which are meant to speed up queries, sometimes don’t work as fast as you’d expect. The article, Slow Indexes, explained that while the initial tree traversal part of the index is efficient there are two other steps that can slow things down. First, when there are multiple matches the database has to follow a chain of leaf nodes to find all the entries, which can take extra time. Second, for each match it has to access the actual table data which means reading a lot of additional blocks. These extra steps can make the query slower even though the index itself isn’t "broken" or “unbalanced.” It was interesting to learn that rebuilding the index doesn’t actually solve the issue. The performance hit comes from the natural way the lookup process works, especially when there are many matches to process.