Brandon's Weekly Learning Journal

 Week 5, This week had us practicing more with MySql, using what we already know to find very specific information across multiple tables. In addition, we also learned more about transaction management, such as using commits, rollbacks, and learning about concurrency, schedules and transactions themselves. This could be helpful when preserving information if something unexpected happened. Like someone trying to withdraw cash, but right as the atm is about to dispense the cash and already changed the user's bank information, the power shuts down. This would require measures so that the user's money is protected. However, I have been asked about something intriguing I want to talk about. If indexes are supposed to speed up the performance of a query, then why can indexes be referred to as slow indexes? Markus Winand talks about this in his website "Use the Index Luke". In short, indexes are great for finding something in a large dataset. However, if there are duplicate

 Now we are half way through the course, and there is quite a few things that I have learned so far. For starters, I have learned a lot about how to use MySQL, using all the basics, using different methods of joining tables, creating views, and subqueiries. I also learned a good bit about normal form, an example being the third normal form, where all non-key columns must depend on the key, the whole key, and nothing but the key. So if a table has a key of one column, all non-key columns must depend on it, or if there are multiple columns in a key, then all non-columns must depend on all of those key columns(not part of it). As well as non-key columns must only depend on key columns, and not other columns. I also learned more about entity relationships. Whether the relationship is weak or strong, and if it is one-many, one-one, or many-many. However, there are still things I am confused about. I can put the pieces together with normalization, however, when viewing tables it still takes

 Week 3! One thing that is considered important in database engineering is the normalization rule which reduces redundancy in tables. Focusing on the third normalization rule (the combination of the first two rules plus a third rule), Edgar Codd, considered as the father of relational databases, once described the third normalization rule as "a non-key column depends on the key, the whole key and nothing but the key, so help me Codd." where the key means primary or other candidate key of a table, whole key referring to a key containing multiple columns, including them all not just some columns of the key. Essentially, what is being said is the fact that non-key columns must depend on or are related to the key to each row. If it is not related to a key, then the database is not in normal form. This is important because it maintains the integrity of data, preventing redundancy or repetition and makes the data consistent. One thing we used recently in MySQL a view which is essen

 Week 2! Something we worked with this week was the ability to join tables on any column. Normally, the join would use equality between the primary key and the foreign key. However, there are times where joining something other than keys would be necessary. For example, I can say I want to select the column "title" from the table "video_games" and the column "name" from the table "company" by joining where the "video_game" column "developer_company" is equal to the "company" column "name". In SQL, it would look like "SELECT video_game.title, company.name FROM video_game, company where video_game.title = company.name;". This would return the values of each column from both tables into one where the column values match. So far, SQL is taking a bit of effort to get comfortable with. However, once I understand it, it is easy to use. Most of the time, the translation between English and SQL is smooth.