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...