Posts

Showing posts from September, 2024

CST363 Week 5

If indexes are supposed to speed up performance of query,  what does the author mean by a slow index?       In the context of database performance, a slow index refers to an index that does not effectively enhance the speed of query execution, potentially leading to slower overall performance. This can happen for several reasons, such as when the index is not properly aligned with the queries being executed, or when it contains too many entries that are rarely used. Additionally, if the index is updated frequently due to insertions or deletions, the overhead from maintaining it can negate any performance benefits.      The author emphasizes that while indexes are intended to optimize query speed, poorly designed or misused indexes can actually lead to inefficiencies. For instance, if an index is created on a column with low cardinality (few distinct values), it may not provide much benefit for filtering results, resulting in the database still nee...

CST363 Week 4

   Briefly summarize 5 things what you have learned in the course so far.       First, I've learned the fundamentals of SQL, including how to write queries for data retrieval, insertion, and updates. Second, I’ve developed an understanding of database normalization, which helps minimize redundancy and improve data integrity. Third, I've explored various data types and their applications, allowing me to choose the right type for specific use cases. Fourth, I've delved into indexing and its importance for optimizing query performance. Finally, I’ve learned about relational database design and how to effectively model real-world scenarios using entities and relationships. List at least 3 questions you still have about databases.        I'm curious about the best practices for managing and maintaining large databases, particularly regarding backup strategies. Additionally, I'd like to know more about how database security measures are i...

CST363 Week 3

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 essentially a virtual table created by a query that selects data from one or more tables. It looks and behaves like a table when you query it, but unlike actual tables, views do not store data themselves. Instead, they present a dynamic result set based on the underlying tables. Unlike tables, views usually cannot be modified directly; insert, update, and delete operations are typically restricted, especially for complex views involving joins or aggregations.   2. We have completed our study of SQL for this course.  This is not to imply that we have studied everything in the language.  There are many specialized features such as calculating rolling averages, query of spatial data (data with latitude and longitude) coordinates, and more. But take a minute to think about how SQL comp...

CST 363 Week 2

1. SQL has the flexibility to join tables on any column(s) using any predicate (=, >, < ).    Most of the time the join will use equality between a primary and foreign key.   Think of example where joining on something other than keys would be needed.  Write the query both as an English sentence and in SQL.  If you can't think of your own example, search the textbook or internet for an example. One example where joining on something other than keys is needed involves combining tables based on a non-key attribute. For instance, if I want to find customers who have made purchases in the same month, I might join the Customers table with the Orders table based on the order date and customer ID. The SQL query would look like this: SELECT c.CustomerID, c.CustomerName, o.OrderID, o.OrderDate FROM Customers c JOIN Orders o ON c.CustomerID = o.CustomerID AND EXTRACT(MONTH FROM o.OrderDate) = EXTRACT(MONTH FROM CURRENT_DATE); In this query, I'm joining the...

CST363 Week 1

1. Relational database tables and spreadsheets look similar with both having rows and columns.  What are some important differences between the two?   Relational databases and spreadsheets might look similar because they both have rows and columns, but they are quite different in how they manage data. Databases can handle lots of data and keep it organized using rules like unique IDs and links between different tables. They’re built to deal with many users working at the same time and can keep track of complex relationships between data. Spreadsheets are great for smaller tasks and simpler data, but they can get messy with a lot of information and don’t handle multiple users very well. They also don’t have the same level of data protection or advanced searching features that databases offer.   2. Installing and configuration a database and learning how to use it is more complicated that just reading and writing data to a file.  What are some important reasons tha...