Posts

Showing posts from September, 2024
So far in this course I have come to understand how relational databases work and why they are so much more powerful than basic spreadsheets. One of the big concepts has been normalization which is all about organizing data in a way that reduces repetition and keeps everything efficient. I’ve learned how to break large tables into smaller ones and link them using foreign keys to maintain relationships between different types of data. SQL has been the major focus, specifically using JOIN operations to pull together data from multiple tables at once. Indexing is another key thing I’ve picked up. It’s crucial for speeding up queries, especially with large amounts of data. We’ve also worked with SQL views, which are virtual tables that make complex queries simpler. And figuring out how to auto-generate primary keys which has made it clearer how databases manage unique identifiers for records. Looking ahead, there are still a few things I’m curious about: How can I use indexing in really la...
This week, We explored SQL views and how they work. An SQL view is like a virtual table that shows data from one or more real tables based on a query. It feels a lot like working with a table since you can query a view the same way. But, unlike tables, views don’t hold any data themselves. They just store the SQL query that defines what they display. This also means you can’t always perform INSERT, UPDATE, or DELETE operations on a view without restrictions, and they don’t have primary keys. Thinking about SQL compared to a language like Java, there are some cool overlaps. For example, how SQL's WHERE clause is kind of like Java's if statements or how the SELECT statement in SQL is similar to Java's return statement since it decides what comes out of the query. But there are also big differences. SQL is great for working with large sets of data all at once, while Java offers more control over things like loops, object-oriented programming, and detailed logic. Each language ...
SQL is a really versatile language, letting you join tables on almost any column using various predicates. Most commonly we join tables on primary and foreign keys with equality. But there are times when you might join on different columns. For instance, imagine you want to link a table of employees with a table of projects based on job roles instead of IDs. In short, you could say: "Find all employees and the projects they are working on where the employee’s job role matches the projects required role." Heres how you would write that in SQL: SELECT employees.name, projects.project_name FROM employees JOIN projects ON employees.job_role = projects.required_role; I find SQL to be a powerful and fairly intuitive language for working with databases. It’s straightforward for basic tasks but can get tricky with complex queries. Dealing with nested queries and multiple conditions can be challenging and often requires a solid understanding of both the database structure and the logi...
While relational databases and spreadsheets look similar with their rows and columns, they serve different purposes. This week, working with MySQL and Java showed how databases handle large datasets and complex queries better than spreadsheets. Databases also enforce data integrity and manage concurrent access, features spreadsheets lack. Unlike spreadsheets, databases are designed to scale efficiently and maintain accuracy even with numerous users. Setting up a database can seem complicated, but it's valuable for its ability to manage and analyze data effectively. Understanding these concepts will be crucial for any data-focused career. In this course, I'm eager to learn more about database design and SQL queries, which will be really useful for any future job in the field.