So take a look, we'll begin with the Actor table here. And I want you to notice, if we view the content, that each record has a unique identifier, called Actor ID. So Penelope is 1, Nick is 2, Ed is 3. Now the key thing to understand is the way this table was set up, no record may share this identifier. So if I try to change Dan's ID to 3, nope, it's not going to let me. Duplicate entry 3 for key Primary. OK, so what is Primary? A primary key is a unique identifier for a record.

You can duplicate that as much as you want because it's a simple integer. So it sounds like we need something that explicitly says this field is the primary identifier for the record. OK, let's switch back. I will remove that extra ID example. And I want you to notice for ActorID, there is this section, this column here called Key. And under it, we can see ActorID is the primary key. And then we also have this AutoIncrementExtra. What that means is each time you add a new record, we will increment the number from the previous.

What that means is each time you add a new record, we will increment the number from the previous. So for example, let's go to the most recent one, it's 200. If I add a new record, because we have AutoIncrement turned on, it will automatically be set to 201. And you'll see that right there at the top. That way you don't have to manually be in charge of that. OK, so if ActorID is the primary key, or the primary identifier for a record, that would mean, as we've already learned, that there's no option for two records to share the same ID.

would mean, as we've already learned, that there's no option for two records to share the same ID. If I change this to 50, nope, there already is an actor with an ID of 50. You have to use something else. So if we use a comparison from the real world, it would be like your social security number. No two people may share the same social security number. It would defeat the entire purpose if they did. Now if I click over to the table information, you'll see right down here, this will show you the SQL to generate this table. And you'll see here for Actor ID, we've specified it's a small integer.

The point is, we now have a pointer to this specific record. Think about it. If we did not have this actor_id column, it wouldn't be so easy to find this exact record. Because think about it. There could be multiple people with the same name. Nothing wrong with that. So if we didn't have an identifier, if we didn't have a primary key, how would we know which Gregory Gooding we were referring to? You wouldn't. It would be a big problem.

You wouldn't. It would be a big problem. So as a general rule, most of your tables are going to include a primary key. Not all. There will be exceptions. But again, as a basic rule of thumb, your tables should have a primary key. Now you'll notice, though, for this database, the conventions are slightly different from what you might be used to with Laravel. And that's entirely OK. So you will notice that the table names are singular, whereas for Laravel, the default

And that's entirely OK. So you will notice that the table names are singular, whereas for Laravel, the default is plural. So in a Laravel app, again, the convention, you can do whatever you want, but the convention would be to name this table Actors, and Addresses, and Categories, and Films. OK, next, on top of that, the primary key here is Actor ID. Again, maybe a little more common these days. It just depends on the community, to be honest. But a little more common these days is to strip the prefix there. So in my own projects, this column would simply be ID.

But a little more common these days is to strip the prefix there. So in my own projects, this column would simply be ID. For the Film table, this column would not be Film ID. It would be ID. But it doesn't really matter. Simply pick one and stick to it. OK, so I'm going to switch back to this Actor table. We've now learned that a primary key is a unique identifier to one record, and it cannot be repeated. But next, you've likely also heard this term Foreign Key.

be repeated. But next, you've likely also heard this term Foreign Key. So what exactly does that refer to? Let's review another example. If I click on the Film table, you'll notice that each film has a column called Language ID. And this will be the language the film is spoken in, I assume. So we can gather, through Language ID, that it's referring to something over here. OK, probably Language. And here's a list of supported languages for all of the films.