Some projects will require Foreign Keys to be used. Basically, this means that the primary key of one table, when used in another table must exist and will be enforced when updating or deleting rows. For example, if you try to delete a row from one table that has a Foreign Key in another, the database will not let you delete that row. It basically creates an immutable bond between a row in one table and a row in another table.

There are upsides to this system. For example, you can't have any "dangling" data. You can't delete something and then have a situation where you only have partial data.

The downsides to this is it makes the database slower, because it has to check different places in each table to make sure that things are consistent.

Some companies don't use them for the reason that they are slow. For example, Facebook does not use Foreign Keys. What's the compromise? They just don't delete anything. Makes sense...

I personally don't use Foreign Keys in any of my projects and follow the "don't delete anything" mantra, so we'll leave Foreign Keys for another time. For the average application that is running in todays day and age, you don't really have to worry about storage. 99% of applications won't hold more than a million records and holding a million records is trivially expensive to store.

If you need to make things disappear, but not actually delete something, a strategy is to just mark a row as deleted aka update the row and say deleted = true.

In later lessons, we'll implement Foreign Keys and watch how they act compared to regular keys.