9 hours 41 minutes
Welcome back to Muzzle four. This is less than 4.4 implement constraints. This lesson. We're gonna add the constraints to our migration files. We already have some constraints. The primary keys are a type of constraint. The primer key is again required to be unique.
We're going to add the foreign key constraints which will help protect referential integrity.
And we will cascade changes. So when a user is deleted, then their references on their pivot table will also be deleted.
We're also going to add a unique constraint. We're gonna have this on the pivot table. This is going to prevent teachers and students from enrolling in the same course because the combination of the course and the user I d. Will be required to be unique. So why do we use constraints? Well, it protects referential integrity, it
clearly indicates, designed to other programmers.
When you when I see a foreign key constraint on two tables, I clearly see that relationship. I clearly see that there's intention there when it's not there. I kind of
depending on the naming of the columns might have to guess,
and depending on the size of the database, you could end up doing way too much guessing.
And, of course, and including these prevents technical debt.
Now, with that said, let's go ahead and get started.
Okay, here we are. I have my migrations folder area open, and that's in my shared database migrations area. These are the migration falls to get created when you create the model with the migration. And I'm looking at my er de diagram to see where I need to add those foreign key constraints.
I can see that I'm gonna need them on grade, user
essentially anywhere where I see this little fork connecting to a table. So let's go ahead and start with the grade table.
Gonna edit that,
and then I'm gonna paste in
the foreign key constraint that a copy from the documentation
You can see that this isn't correct because we aren't on. We don't have a user. What we do have a user. I d.
So maybe this one is correct. Use your I d
references. I d on users
Cascade. Okay. Yes, that is correct. So it just happens that the example I copied from the label documentation also happens to be the exact foreign key constraint I need, But we need another one to the course I d
So we'll change. User, I d to course I d
references. I d on course this
this is in the plural. The table names are plural while on the rd diagram, it's singular.
So foreign course A D references I d on courses on delete Cascade. Okay, go ahead and save that.
Now, the one thing here is that great is gonna try to connect to the course table. So that means the course table will have to exist before that happens.
And the way PHP are Titian migration files work is that they run in the order of the date stamp,
and that's in ascending order. So if I move this or if I changed the date to before
the great table that I should be OK,
for 06 Now, this is in my situation. It's very, very likely that you created your files with different date and time steps, so you will need to change the date and time
to one that places it right before your users table.
So now I have courses and users,
so you probably will not be able to copy exactly what I types will be sure to pay attention to those time stamps and name that, respectively, so that it occurs before your users table.
So we have courses, users,
grades. So when we get to grades,
the user table will exist and the course table will exist. Okay, that's going to run that migration just to make sure that works correctly.
So PHP are Titian migrate fresh.
We got an exception. Let's see what we have.
Incompatible. Okay, so we're not using the right data type on one of these, So let's check the grades.
Big energy. Okay? They're not unsigned. They need to be unsigned
both of these
because we can't match an unsigned against a
regular one because the big increments
It's going and run that again.
No, you gotta spell it right.
there we go.
So, once I added the unsigned command to the migration file, it worked correctly.
Okay, let's move on to the other tables. Let's go ahead and take care of
user course. That's gonna be the probably the most complicated one.
So I'm gonna copy the foreign key from my other one and eminent rename
to the correct column names,
so we have a course I d references I d. On courses that's actually correct
on, uh, let's go ahead and copy and paste again.
Then we have We're gonna need the user. I d
references. I D on users.
On next. We need the type I D
purposes. I d on
Cascade wouldn't save that.
Now. This one has three other tables that will need to exist before it's created. So let's make sure that that's true. Users Table does exist
courses Table is true.
User type is true.
That looks like it will work. Let's go ahead and run that migration.
And if it's different for yours because you created them in a different order, you will want to make sure that they are in the correct order.
Let's go ahead and run this
and I made a spelling air here, so it's going to fix that
and rerun it again,
and we are good to go.
Let's move on to the next table,
go ahead and take care of the course table.
Well, that's going to be this one,
and I know we're gonna have to change one of the tables, the room.
and room I d
purpose since I d on rooms.
All right, so we will need the rooms to occur before that.
So it looks like weaken or I can change this to
That should work
on. Let's go ahead and run the migration just to make sure
we're good to go.
Let's move on to the room file.
So it's gonna need another one before that one,
and it's gonna be the building.
building I d
or Mrs I d on buildings
so well, it's gonna fail. We don't have buildings in the correct place.
it's like I could change this to six
on a 33
That should put everything in the right order. Run it again.
Okay, Looks like that worked. So we've added all our constraints. Let's go ahead and take a look in d Beaver and see their e. R D. Diagram is looking correct,
right? Click Refresh.
I want to go into the most complicated one, which is user courses. Look at the E. R. D diagram
and there we go. We could see
that those are constraints have been added incorrectly.
And the nice thing about constraints is that as a if you are a different program or a new program are coming in,
you'll be able to look at this and say, OK, user courses is related to all this stuff,
which, you know is somewhat apparent just going by names. But as databases get more and more complicated, it's very helpful to have these in place.
So let's go ahead and head over to the summer and talk about what we went over in this lesson.
Oh, I do have one last thing to implement before we go over to the summary.
I almost missed this, but we need to implement our unique constraint, and that's just table arrow unique. And then the square brackets don't forget that. That indicates an array
and then user I d in combination with Type I D. In combination with course, I d is required to be unique.
I'm going to save that,
and I'm gonna run the migration again.
And if we look at our d beaver, we can see that
on the user courses table within constraints, we have that unique constraint indicated by the key
so that completes that on Let's move on to the summary.
And that brings us to the 4.4 implement constraints summary. And this less than we implemented foreign key constraints. We implemented a unique composite key constraint that was on the pivot table that required that the user i d and the course I d be unique in combination.
We fixed some errors that we encountered my gracious need to occur in the correct order.
A migration will drop all the tables, and all the tables will be recreated, so you cannot implement a foreign key on a table that does not exist yet. So, for example, if you have five files and in file to you are
implementing a foreign key constraint to a table that is created in File three, that's going to fail because File three has not run yet.
Unique command requires a list in and Ray indicated by the brackets
and data types of must match. Being imager will not match with big imager unsigned, and that is because big imager without the unsigned call means that it could be native or positive, whereas big energy or unsigned can Onley be positive. So there's the possibility
that you would have some integrity loss in your data. If you are able to match those against each other,
that completes this lesson, and I hope to see you in the next.