So let's set up the rest of our foreign keys, and we've already done the ones for the reservations
table that links room ID in the reservations table to ID in the rooms table.
And it looks like we have two more, both on the room restrictions, table one that links again, room
ID in this table to the ID column in the rooms table and one that links restriction ID to the restrictions
table column ID so we can do both of those foreign keys in one migration.
So let's do that.
Go back to our idy open a terminal window.
So to generate fees and I'll call this create F and the table is called room restrictions for room restrictions
and that should generate both of our up and down migrations.
And there they are.
So let's do the up one first.
So what I'll do is just take this foreign key that were created in the last lecture and paste it over
here twice.
And the table is room restrictions.
So I'll copy that, put it in the second one and the first one is room ID to rooms caller ID.
So that's OK.
And the second one is for restriction need in the table restrictions column ID.
So that should be fine.
Let's run that migration.
So to migrate.
No they're OK.
And now let's do our down migrations.
So again I'll copy the down migration we did last time and paste it in the down migration's for here
twice and then just modify.
So the table is again room restrictions.
And we need to get the name of the foreign keys, so I'll go over to divert and refresh the foreign
keys on the room restrictions table.
And there are two room restrictions, restrictions, ID and room restrictions, rooms, ID.
So room restrictions, restriction, I.D..
I think that's right.
Room restriction restrictions, plural.
And then instead of room restrictions, restrictions, it's room restrictions, rooms, and that should
work.
So let's try running that just to make sure this is going to work the way we want to sort of migrate
down.
And it gave me an air room.
Restrictions, restrictions, ID of room restrictions does not exist.
So I got the name wrong room restrictions, restrictions.
ID underscore, of course, underscore Kerry.
Underscore.
OK, let's try that again so we'll clear the screen and sort of migrate down.
And again, line two expected next token to be apparently I can't type today.
So line to room restrictions, room restrictions, rooms, I'd try that one more time and hopefully
it didn't run the first down.
That's better.
And now if we go look at this and refresh our foreign keys, there they are.
And if we run the migration again, so to migrate now, they should be here when I refresh this.
Another.
So there's all of our foreign key setup, is that everything we need to do?
Well, no, it's not.
There are a few other things we want to do.
For example, in the user's table, we have this column ID and that's what people are going to use to
log in.
They're going to type in their email address and a password.
And what we want to make sure is not possible is that we can have two users with the same email address.
So we want to add a constraint on this table that makes the email column unique.
So we'll do that for sure.
The second thing is sometimes you're going to have a lot of data in a table.
And, for example, this reservation table is going to have a lot of reservations over time.
The room restrictions table is going to have a great number of restrictions over time.
If this site's up and running for, say, two years, there might be 100000 entries in the room restrictions
table indicating when reservations are blocking dates off, when the property owner has decided to block
a given date or range of dates off.
Whatever the case may be, there's going to be a lot of data in there.
And if we don't do something to speed up access to that table, it will be very, very slow to read
through.
It will wind up doing is what's called a road level table scam, where in order to find, for example,
all of the restrictions for a given room, the database will actually scan through the entire table
looking for things that have a given remedy and that's not efficient at all.
And we can speed that up a lot by putting an index on a given field.
So, for example, if I put an index on the remedy that the database will actually store a method of
accessing information about the room restrictions table for a given remedy very, very quickly.
So we're going to want to add one or more indices on the tables.
So we'll take care of that in the next couple of lectures.