9 hours 41 minutes
I welcome back to Mosul. Five. This is less than 5.3 composite key composite keys are commonly found in commercial databases.
Composite key is when two or more keys indicate a unique record, and by keys I mean columns.
It's similar to a unique constraint.
A typical implementation you will see in commercial databases is the presence of a company I d. Column. You then have to use that company. I d in many of your queries to make sure that your tarting targeting the right company.
This allows software users to implement multiple departments, divisions or companies.
If you're right inquiries for a company that uses such a database,
you should write your queries in a way that uses the composite key, even if the database application currently does not have another company in it, because the users haven't
decided to use that future yet.
And the reason you want to do this is that if the decision is made later to add a company to the application and all your queries are written in a way where the assumption was made, that there would never be another company added,
they will avoid all your queries
so shown below is a simple query that respects a composite key.
So this works with one company or if multiple companies are in use, and in this example, it joins two tables by both the company i D and the B account I d.
Now. With that said, let's take a look at a diagram, often implementation of a school table that we're going to use in our database to implement a composite key. Here is the update of the ER de diagram. You can see this getting more complicated.
We have added a school table that will now be related to all the other tables by implementing a foreign key constraint on a school i d column.
And when we write queries against this database, we will want to write many of our queries to just include the school i D. Even if the school ideas not in use by the table connections.
Now it is common for er de diagrams to get more and more complicated as the database grows, and typically to deal with that, What you would do is you would exclude relationships that you're not investigating or you're not working with. For example,
once we know that school relationship is there. We may remove it from the RD diagram
so that we could get a cleaner look at the specific relationship that we're interested in looking at now. With that said, let's go ahead and implement this table. OK, I have a shell session open to the vag machine. I'm in the correct directory and I have my previous make model command, but I need to change it to the
the new model, which is school.
I'm gonna go ahead and go back to building and change it to school,
and we believe this dash dash migration on because that's going to create the model and the database migration. Our primary interest will be the database migration, but we might use the model later, so I'll go ahead to make that part of the command
so successfully created that table
and let's go
and find it.
So in our database migrations holder, I can see that we've added the school's table.
Now we're gonna have a foreign key constraint coming back from all the other tables, so we're going to need to move it up all the way to the front so that it's the first table that gets created, and we'll do that by changing the date on these migration files. So 10
05 and you will have to change the date
to the day and times that are reflective of when you created them.
and we need to add the columns
and we don't have that many columns.
We have a name
and we have a description
I had to make that text.
I think that's the right one.
When you go ahead and save that
now, on the other tables, we need to add the foreign key constraint.
So first I'll start with the users table. Actually, I will go to a table that has a foreign key.
I'll start with the users table.
Andi, I will need to change this.
Let's see here so foreign.
Actually, we also need to add a
We need to add the calm.
we need one of these big energy on sign columns from borrowed that from here,
and we will call this school idea
and then foreign school I D
preferences. I d on
on delete Cascade. That should work.
Go ahead and copy they used to together so I can just paste into my other files.
That should work
this right here
on pace. This right here,
pace. That's right here
paste it right here.
Okay? And then I want to save all.
And I think we are ready to run the migration and make sure that it works Are db cedar?
I don't believe we'll work, so but we're gonna fix that in the next lesson.
my great fresh.
Okay, It says I have a duplicate column. May about. I already had that somewhere.
School I d
great table users. Okay.
I need to delete this one.
Can't have two columns with the same name
and hit up.
Rerun the migration,
and it looks like it worked. I'm going to D beaver.
We're going to refresh it
on going to double click on this on the database name.
Go to the er de diagram
on. We can see.
we didn't need that on school, So let's go back into these schools table.
So I just want to my files and connected it
so it's actually unnecessary on this table.
Let's go ahead and save that and rerun the migration
and we'll go over here and refresh.
There we go
and we can see all our foreign key constraints lining up.
And in the next lesson, we're going to fix our devi cedar so that we see data in different schools.
So let's go ahead and head over to the summary.
So that brings us to the 5.3 composite key summary.
We discussed composite keys in this lesson.
They are commonly found in commercial databases.
We implemented a new school table to implement our own composite key, and the next lesson. We are going to fix our database cedar so that we can cede data at different schools. And we also reviewed and updated the ER de diagram, which will, of course, be available for download as well.
And that completes this lesson. I hope to see you in the next thank you