My CS Degree Journey

   WK04:  Midpoint Reflections I'm not new to databases and have some practical experience with SQL, but this course gave me the theoretical backbone for concepts I've used pragmatically. I connected everyday tasks - designing tables, choosing keys, writing joins, and skimming plans - to the relational model and formal normalization. Seeing why clustered vs. heap layouts affect access, how B-tree indexes support equality/range predicates, and where optimizers derive their strategies clarified earlier "rules of thumb." Overall, I gained vocabulary and structure to justify design choices. Brief Summary of 5 Things Learned I strengthened the relational model: entities/attributes, candidate vs. primary keys, and why foreign keys enforce meaning across tables. I practiced expressive SQL beyond basics - joins, subqueries, and aggregates - while reading execution plans to understand scans, seeks, and join algorithms. I deepened constraints and referential integrity to preven...

   WK03:  Completing our study of SQL This week capped a very short introduction to the language: we touched nearly all the basics but didn't drill deeply. Even so, it clarified a lot. I especially liked finally seeing how indexes work under the hood - why they speed equality/range lookups, when they hurt writes, and how choices like clustered vs. heap storage change access paths. We also took a quick look at query execution plans. Reading operators such as full/index scans, unique-key lookups, nested loops, DISTINCT, and ORDER BY made the optimizer feel less magical. I only wish we had spent more time interpreting plans and estimating costs. SQL Views A SQL view is essentially a saved query that presents data as if it were a table. Like a table, you can select from it, join it, or filter it. The big difference is that most views don't actually store data - they are virtual, built on top of base tables. Because of this, they don't usually have their own primary keys. Whet...

   WK02: Learning more about SQL This week we kept building on SQL fundamentals and stepped into more complex territory. We explored joins - inner, outer, left, right, and self - seeing how they stitch related tables together and how predicate placement in ON versus WHERE can change results. We also practiced set operations like UNION/UNION ALL to combine or compare result sets. On top of that, we wrote nested subqueries with IN and EXIST and discussed how NULL and three-valued logic affect predicates. The big theme was translating real questions into set-based thinking: composing queries step by step, choosing the right join, and validating assumptions. A common case for joining on something other than keys is a range join, where rows match based on whether a value falls within an interval rather than by equality. For example: For every employee, find the salary grade whose range contains the employee's salary. Here there's no foreign-key relationship between Employees a...

 WK01: Starting CST363 – Introduction to Databases This week I officially started a new course: CST363 – Introduction to Database Systems . The class looks like a solid mix of theory and practice. We'll design relational schemas, practice SQL queries, connect to databases programmatically, and even touch on NoSQL concepts like MongoDB. The syllabus makes it clear that this isn't just about running commands - it's about understanding the underlying algorithms, data structures, and principles that power modern database systems. That excites me, since databases are everywhere, from apps to analytics pipelines. Relational Databases vs. Spreadsheets At first glance, relational database tables and spreadsheets look the same - rows and columns full of data. But digging deeper, the differences are critical. Spreadsheets are flexible but mostly unstructured; you can mix data types freely, create ad hoc formulas, and manually tweak things. Databases, on the other hand, enforce stric...