My CS Online Journey

This course helped me understand how databases really work and how much thought goes into building them correctly. The three most important things I learned are database design, SQL querying, and how databases connect to real applications. 1. Database Design and Normalization Early in the course, I learned how to take messy real-world information and organize it into clear, structured tables. Normalization, especially the first three normal forms, showed me how to prevent duplicate data and keep everything consistent. Working on the prescription database lab made this feel practical. I saw how choosing the right primary and foreign keys can make inserts, updates, and lookups smoother and more reliable. 2. SQL Querying and Joins Writing SQL queries became one of the most useful skills I picked up. Learning how to use SELECT , JOIN , and GROUP BY taught me to think logically about how data connects across tables. It wasn’t just about remembering commands; it was about asking the rig...

 MongoDB and MySQL are both widely used databases, but they serve different purposes depending on the type of data and the goals of the application. MySQL is a relational database that organizes information into tables made up of rows and columns. It uses structured query language (SQL) to define schemas, create relationships, and perform queries such as SELECT , JOIN , and UPDATE . MongoDB, on the other hand, is a NoSQL database that stores data as flexible JSON-like documents inside collections. Each document can have its own structure, which makes MongoDB more adaptable to unstructured or frequently changing data. Both systems share some important similarities. They are open source, support indexing for faster data access, and allow basic operations like inserting, reading, updating, and deleting data. Both also offer replication for high availability and tools for monitoring and backups. In our SQL labs, we practiced commands such as CREATE TABLE , INSERT INTO , and SELECT *...

I finished the Lab 18 peer reviews and focused on whether each ER diagram actually supports the prescription workflow. The strongest designs kept prescriptions separate from fills and stored drug prices in a way that preserves history, which makes reporting and auditing sane. I flagged fixes like using IDs for foreign keys instead of names, adding required attributes such as a pharmacy phone, and tightening a few relationship cardinalities so the rules are explicit. I also looked for basic normalization slips and confirmed that the chosen keys would prevent duplicate patients, doctors, and fills. The point was not the diagram aesthetics but whether constraints and keys would keep real data clean and predictable over time. I also moved from Workbench queries to JDBC inside a small Spring MVC app and got comfortable with the essentials. I bind inputs with prepared statements, remember that parameters are 1 based, iterate result sets cleanly, handle NULLs correctly using wasNull for prim...

This week, we focused on database transactions and concurrency control. We learned that a transaction is a sequence of operations performed as a single, atomic unit to ensure the database moves from one consistent state to another. If a transaction completes successfully, its changes are committed; if it fails for any reason, any partial changes are rolled back, preserving data integrity. A primary reason for using transactions is to manage concurrency, which is when multiple programs or requests run at the same time and access the same data. Without proper controls, concurrency can lead to several problems. We examined the "lost update" problem, where two transactions read the same value, and the second transaction's write overwrites the first, causing the first update to be lost. We also looked at "inconsistent reads," where one transaction reads data that is only partially updated by another, leading to incorrect results. Another issue is the "inconsiste...

As we reach the halfway point of the course, I've had the chance to learn several foundational concepts that build on each other, moving from writing queries to designing the databases themselves. Five important things I have learned so far: Advanced SQL Querying Techniques: Beyond basic SELECT statements, I learned how to refine query results. This includes using  DISTINCT to eliminate duplicate rows and the  LIKE predicate with wildcards ( % , _  ) for powerful pattern matching in strings . I also learned how to use built-in functions to manipulate data, like concatenating strings or rounding numbers directly within a query . The Power and Variety of JOINs: I now understand that there are multiple ways to join tables, from the modern INNER JOIN syntax to the older comma-based syntax . A key takeaway was the practical use of a  LEFT OUTER JOIN to find information that is "missing", for example, to list all instructors and show a count of zero for those who ad...

1.  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) ? An SQL view is a virtual table whose content is defined by a query. Think of it as a saved SELECT statement that you can interact with as if it were a real table. It doesn't store any data on its own; instead, it provides a dynamic "window" to view data from one or more underlying base tables. Similarity to a Table The main way a view is similar to a table is in how you use it. You can query a view with SELECT , filter it with WHERE , and JOIN it with other tables, just as you would with a physical table. This is its primary benefit, as it allows you to abstract away complexity. A user can interact with what might be a complicated, multi-table join as though it were a single, straightforward table. Differences from a Table The differences are crucial for understanding database structure and performance. Data Storage: A ta...

This week, we moved into advanced SQL, focusing on sophisticated ways to join and query data. I learned about different join syntaxes ( NATURAL JOIN , USING ), the power of LEFT JOIN for creating summaries that include zero-count groups, and set operations like UNION . The lessons on self-joins and WITH RECURSIVE for querying hierarchical data were particularly insightful. A key takeaway was the strategy of breaking down complex problems into smaller, incremental SQL steps to build a final solution. Prompt Answer Non-Key Join Example A common scenario for a non-key join is assigning employees to salary grades based on a range. English Sentence: "For each employee, find their salary grade by matching their salary to the grade's minimum and maximum salary range." SQL Query: SELECT e.employee_name, e.salary, sg.grade_level FROM Employees AS e  JOIN SalaryGrades AS sg ON e.salary BETWEEN sg.min_salary AND sg.max_salary; My Thoughts on SQL SQL is a powerful and decla...