Posts

Week 8 - Reflecting on the Three Most Important Learning Moments in CST363

Briefly summarize the what you consider to be the three (3) most important things you learned in this course.           On the other side of CST363 Intro to Database Systems , I have gained a deeper understanding of how databases are a foundational part of the programming landscape and how they integrate with broader software systems. One of the most important takeaways was learning how data is not only organized but also preserved and managed for long-term use, ensuring reliability and consistency in real-world applications in industries with small margin for error, such as medical, educational and financial technology. I also developed a clearer grasp of how entities and their attributes relate within a database, which helped me understand data modeling and relational structures more intuitively. Finally, working hands-on with MySQL Workbench, Java integration, and MongoDB gave me practical experience in both relational and non-relational systems, reinfor...

Week 7 - MongoDB vs. MySQL Reflection

  Prompt for this week's journal entry. Compare MongoDB with MySQL.  What are some similarities?  What are some differences?  When would you choose one over the other?           While MySQL provided a very point-and-shoot process with its application, MongoDB has felt a little more abstract and esoteric running predominantly through commands and notepad scripts instead of a central program. Having only previously worked in IDE's, I found MySQL to be instantly familiar. Learning and troubleshooting in MySQL is not completely unlike Java--having a log that acts as a console from which to diagnose error messages is fundamentally parallel to troubleshooting in an IDE. Writing code in a notepad file and saving it as a JavaScript file is quite removed from my prior coding experience but felt quite magical to get familiar with for these MongoDB assignments. I would say the conceptual database functions are where MongoDB and MySQL are most simi...

Week 6 - Weekly Reflection

          Week 6 of CST363 offered many learning opportunities both in assigned reading and labs. While the reading gave the initial rundown on database connections, query execution, and the use of prepared statements through APIs like JDBC, the Java labs offered hands-on teaching moments that clarified how to use these concepts in practice. Working directly with JDBC to manage connections, execute SQL queries, and handle transactions worked wonders in solidifying the material. Experiencing Java interface with SQL through IntelliJ and MySQL Workbench additionally contextualized using Connections and using prepared statements to aid prevention of SQL injection attacks. The conceptual topics tackled in the reading are an aspect of computer science that I am always compelled to learn about--in this case it is the different programming paradigms when considering SQL in the context of application development. Qualifying the differences between imperative and dec...

Week 5 - Slow Indexes Reflection

 Referencing  Slow Indexes in RDBMS : if indexes are supposed to speed up performance of query, what does the author mean by a slow index?       In my time working with indexes thus far, I have seen what miracles they can work for improving query performance. This is my first encounter with unpacking how indexes could actually slow a query down. Author Markus Winand illustrates how index lookups can still be slow and expensive even when functioning properly. Winand explains how index performance entails more than just tree traversal in a clear and inviting fashion. First, the lookup conducts the tree traversal by navigating down the index B-tree to reach the intended leaf node. Upon following the leaf node chain, multiple hits can mean the database needs to retrieve all matching index entries. For each matching index entry, the database will then access the corresponding row in the table, which could be located entirely elsewhere in memory or disk blocks. W...

Week 4 - Halfway Through CST363 Reflection

  This week is halfway through the course.  Briefly summarize 5 things what you have learned in the course so far.   List at least 3 questions you still have about databases. Summary of standout learning moments: I have been grateful to learn how databases are structured to store, organize, retrieve, and filter data efficiently. Realizing the extent of database necessity and prevalence in a hands-on and versatile way has revealed how databases are the backbone of software, and--by transitive property--information in a world that persists to move away from any form of physical database. Learning about the relational model and schemas has been eye opening in visualizing how data is manipulated and impacted by structural design. Defining schema and using keys to ensure data integrity in both Java and MySQL have provided different perspectives on the same landscape, providing a well-rounded approach to building further knowledge. Writing a range of simple and complex que...

Week 3 - SQL Reflections

What is an SQL view.  How is it similar to a table? In what ways is it different (think about primary keys,  insert, update, delete operations) ? A view in SQL acts as a fixed and somewhat imaginary table that limits operations done on data and is mostly intended for database users who are not changing data but instead simply accessing it. A view is created with a select statement that will define what can be viewed from the view. Because a view is driven by a pre-defined separate query, it can encapsulate a query that will be reused elsewhere in more complex searches. A few immediate differences between the two are the lack of direct primary and foreign keys when compared to a table. The table is holding the constraints and indexes while the view simply reveals what the underlying table has already established. As the name suggests, a view simply is a view and does not store data the way a table does. Because of these former two facts, insert/update/delete statements are gene...

Week 2 - SQL Reflections

SQL has the flexibility to join tables on any column(s) using any predicate (=, >, < ).    Most of the time the join will use equality between a primary and foreign key.   Think of example where joining on something other than keys would be needed.  Write the query both as an English sentence and in SQL.  If you can't think of your own example, search the textbook or internet for an example. Let's say we want to use a SQL query to count the number of  attack moves that a Pokémon can learn based on its elemental type (like Fire, Water, etc.). We can join the Monster table (representing Pokémon) with the Moveset table (representing available moves/attacks that monster can learn) based on the matching elemental type , even though the move isn't linked by ID to the Pokémon or the move itself. This allows for Pokémon to learn moves outside of their elemental type (which might be tied to the ID) as well as the moves available to them via matching ty...