Week 21 - Mastering Transactions

This week,  a part of a Lab exercise, I learned how MySQL handles transactions and issues with multiple users accessing the same data. I learned how transactions work, where several SQL commands are treated as one unit to keep the data accurate. The lab showed me how row-level locking stops different users from changing the same data at the same time. I also learned about compensating transaction. These types of transactions fix issues after a transaction has already been saved. Overall, I was able to understand how to build systems in a safer way to ensure proper management when errors occur.

In preparation for future collaborative projects and for solidifying my understanding of modeling I created a mockup web design application for a pharmacy database. This helped me strengthen my database design and entity management skills for real-world applications.

Among these things, I also re-enforced my understanding of working with SQL queries in relational databases by working with filtering, groupings, and sorting data.

Prompt:

https://use-the-index-luke.com/sql/anatomy/slow-indexes

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

A slow index is a situation where an index lookup doesn't perform in the way we expected in terms of efficiency. In theory an index is supposed to speed up performance. A reason for slow performance might be that the database needs to follow the Leaf Node Chain to locate matching entries, and this may slow down the process of looking something up. Another reason might be that when the index entries are found, the table data might be spread out and accessing theses additional tables can slow down the query. So the point being made in this article is that the slowness is caused by the necessity of extra steps which might cause slower performance.