Camila's learning journal

We’re halfway through the course, and I feel like I’ve picked up alot more than I expected. In the early labs I learned how to write SQL queries for a single table, then moved on to joins and subqueries to pull info from multiple tables. I also figured out how to use GROUP BY and aggregation functions to answer questions like totals or averages. On the design side, I practiced making ER diagrams and normalizing data so it isn’t repeated everywhere. The labs on keys and constraints helped me understand why primary and foreign keys are so important to keep tables connected. More recently, I worked with indexes, transactions, and concurrency. Indexes are like shortcuts that make searching faster, and transactions showed me how commit and rollback can keep the database safe if something goes wrong. Overall, I’m definately feeling more comfortable with the basics now. I still have a few questions I want to work on. How do I know when it’s really worth creating an index, and when it’s just...

This week I learned about SQL views. A view is kind of like a table, but it doesn’t store the data itself. Instead, it just shows the results of a query. You can use it like a table when doing a SELECT , but the difference is that tables actually hold the data. Tables also have primary keys and you can insert, update, or delete rows. With views you usually can’t do that, or it’s very limited. To me, a view feels like a shortcut to look at data without changing the real table. Since we finished SQL, I also thought about how it compares to Java. Both have ways to handle conditions. In Java you use if , and in SQL you use WHERE . The SELECT statement is kind of like a return in Java because it decides what comes back. The big difference is that in SQL you just say what you want, and the database figures out how to get it. In Java you have to write out every step. SQL is better for working with data, while Java is better for writing programs. They do different things, but they also conne...

  SQL can join tables in more ways than just matching primary and foreign keys. For example, in these recent labs, with the small courses database, we created a view for the average salary in each department. After that, we joined the instructor table with the view to see which instructors earn more than the average salary in their department. In English, the query is: find the instructors whose salary is greater than the average salary for their department. In SQL, the query is: SELECT i.name, i.dept_name, i.salary FROM instructor i JOIN dept_summary d USING (dept_name) WHERE i.salary > d.average_salary; This shows how joins can use a condition like “greater than” instead of just matching keys. I think SQL is easier to learn compared to Java work. It feels closer to English, and when I run a query, I can see right away if I did it right. The harder part is when the question involves grouping or subqueries, because it takes me a little longer to set those up. The m...

 -Databases and spreadsheets both look alike because they use rows and columns, but they are not the same. A database is better when you have a lot of information and when different tables of data need to connect. It also makes sure the data stays accurate with rules, while a spreadsheet is easier to mess up. I see spreadsheets as good for small tasks, but databases are better for bigger ones. -Setting up a database takes more time than just using a file or spreadsheet overall, but a database can hold more information, run searches faster, and let many people use it at the same time without errors. It also has security and backup features, which matter if the data is important. This makes the extra work at the start worth it. -I want to learn how to write SQL and how to design a database that is set up the right way. I think this will help me in the future because I want to work in cybersecurity, and knowing how data is stored and protected is a big part of that. These skills will ...