My CS Online Journey

 Halfway through this course, I can see how much I’ve learned and how it connects to both my past experiences and my future goals. One of the biggest takeaways has been understanding how SQL views work. I now know that a view is like a virtual table, useful for simplifying queries and presenting data, but usually read-only since it doesn’t store data itself. I’ve also learned the importance of normalization, which helps remove redundancy and ensures cleaner updates by splitting one large table into multiple related ones. Another valuable lesson has been comparing SQL with Java: SQL is declarative and focuses on the “what,” while Java is procedural and focuses on the “how.” This comparison helps me appreciate each language’s role in problem-solving. I’ve also seen firsthand how powerful SQL can be in real workflows compared to spreadsheets, such as enforcing business rules like course eligibility in a single query. Beyond SQL, I’ve grown as a programmer in general—planning better, w...

In SQL, a view is like a “virtual table.” It looks and acts a lot like a real table—you can run SELECT queries against it, join it with other tables, and use it to simplify complex queries. A view is created with a saved query, and whenever you use the view, the database runs that query in the background. Views are similar to tables because they let you organize and present data in rows and columns. But they are different in important ways. A view usually does not store data itself, so it does not have a primary key. This also means you often cannot do direct insert, update, or delete operations on a view unless it meets special rules (like being based on a single table without joins). In most cases, views are for reading and organizing data, not for changing it. As we wrap up our SQL study, it’s useful to compare SQL with a language like Java . Both can filter data or control what is returned. For example, a Java if statement is a little like an SQL WHERE clause—they both decide ...

As a college student working toward my Computer Science degree, I’ve been lucky to learn SQL both in the classroom and on the job. At work, I’ve used tools like Smartsheet and an LMS to track training data, and those experiences showed me the importance of being able to ask good questions of data. Now that I’m studying SQL more deeply, I see how powerful it is compared to just managing spreadsheets. What I find most interesting is that SQL isn’t only about joining tables by IDs. Sometimes real-world logic is more complex. For example, I’ve seen training systems where eligibility isn’t just a key match, but based on conditions—like “employees can only register for courses if their years of experience exceed the course’s minimum requirement.” In SQL, I can capture that logic with a simple query: SELECT e.employee_id, e.name, c.course_id, c.title FROM employees e JOIN courses c ON e.years_experience > c.min_years_required; This goes beyond what I could easily do in Smartsheet or Exce...

Relational database tables and spreadsheets may look alike since both organize information in rows and columns, but they serve very different purposes. From my own experience at my previous job, I noticed that spreadsheets became slow and unreliable as the amount of data grew, which made it hard to manage employee training records efficiently. That was one of the challenges I often faced, and it showed me the limits of spreadsheets. Databases, on the other hand, are designed for larger and more complex datasets. They enforce rules like keys and relationships across tables, maintain accuracy, and allow multiple users to access data at the same time without slowing down. Even though installing and setting up a database is more complicated than opening a spreadsheet, I’ve already seen how valuable databases can be. In my previous role, I occasionally used SQL to work with training data, making sure employees’ compliance records were tracked correctly. At the time, I only understood the b...