CST 636 Week 5

This course so far 

As I learn more about database design, I feel curious and excited to understand how data is organized and connected behind the scenes. It’s fascinating to see how concepts like primary keys, foreign keys, and relationships work together to keep information accurate and meaningful. Learning about indexes and normalization helps me realize how important structure and efficiency are when building real-world systems like pharmacies, hospitals, or business applications. Sometimes the topics can feel challenging especially when figuring out why certain queries run slowly or how different relationships affect performance but I enjoy the problem-solving process. 

If indexes are supposed to speed up performance of query,  what does the author mean by a slow index? 

A slow index doesn’t mean the index is slow or broken or inefficient, it means the overall query is slow due to what happens after the index is used. While the tree traversal part of an index lookup is fast and predictable, the database may need to follow multiple linked leaf nodes to find all matching entries and then perform separate lookups in the table for each match. These extra steps can involve many disk reads, especially if the matching rows are scattered across the table, which makes the query slower.

The author calls this situation the myth of the degenerated index, where people wrongly assume rebuilding the index will fix performance. In reality, the index structure is fine; the slowness comes from the amount of data being accessed and the way it’s stored. Even with an index, queries that return many rows or require frequent table lookups can still be slow.