So, now that you're more comfortable with keys, let's take a quick break, switch back to php, and learn how you can represent these relationships with Laravel migrations. So, I'm going to create a new model here, if we're going to stick with that idea of posts. We'll make a Post model, and I'll add the -m flag to add a migration in the process. Next, we'll do it one more time for a Comment that is associated with a Post. OK. Let's go to our create_posts_table migration. Yes, a Post has a title, it'll be a standard string. Next, a Post has a body, and that'll be a text column.

Yes, a Post has a title, it'll be a standard string. Next, a Post has a body, and that'll be a text column. We then have the createdAt and updatedAt timestamps. But you also might want to do one more here. You might want to say, give me a timestamp for when the Post was published, because you can create it before it goes live to the world. So, we'll store the publishedAt time. Now, if this is nullable, we need to be explicit about that. All right. So, yes, I can go ahead and migrate my database.

All right. So, yes, I can go ahead and migrate my database. And if I switch over to SQL Pro, give this a refresh, you can see our posts table in the structure right here. OK. Now, you'll see we have a comments table as well, because we did whip up a migration stub there, but we haven't populated the fields yet. OK. Let's do that now. Create comments table.

Let's do that now. Create comments table. And we'll do this super quick. So, yes, a Comment should have a body. So we'll do that again. But we also need to set up our relationships. So think about it. A Comment is associated with a Post, right? And what is that relationship? It's a belongsTo relationship.

And what is that relationship? It's a belongsTo relationship. Any single Comment belongs to a Post. So table, we'll set up an unsigned big integer for the post_id. Quick note on this, unsigned because it should be a positive number. It's never going to be negative five. And then big integer. This one will throw you off. So I want to cover it real quick. As of Laravel 5.8, all new migrations have the primary key set to a big integer or big

So I want to cover it real quick. As of Laravel 5.8, all new migrations have the primary key set to a bigInteger or bigIncrements. What this means, though, is any time you create a foreign key that references that field, you need to make sure that the foreign key also has the exact same type. Otherwise, it'll throw a foreign key constraint error. So for example, if you were to do this, and assuming this is bigIncrements, it's going to fail. You're going to get an error. So that's something to be aware of.

You're going to get an error. So that's something to be aware of. Next, we need a relationship between the Comment as well as the User who created the comment. So we'll set that up here as well. So let's go ahead and run php artisan migrate, and I'll do the --fresh command. This will drop all of our tables and restart from scratch. There we go. So if I now switch back to SQL Pro, we'll give it a refresh. There we go. So think about it.

There we go. So think about it. If we go to our post table and set up a new Post, we'll set all of the timestamps to now. That's fine. And then I want to create a Comment associated with that Post. So I could say the Post, let's go back, the Post with an ID of one. And actually, you know what? We need a User. So let's do that. php artisan tinker, and I'm going to use the factory builder to very quickly create a generic

So let's do that. php artisan tinker, and I'm going to use the factory builder to very quickly create a generic User, as you see there, Dr. Hopes for. All right. So if I give this a refresh, now I have a dummy User to work with. So we'll say, for the Post with an ID of one, written by the User with an ID of one, we'll have a comment that says, great job here. Excellent. So this is good, but we have an issue here. By default, Laravel is not going to set up any constraints for you.

So this is good, but we have an issue here. By default, Laravel is not going to set up any constraints for you. You have to do that yourself, which means if I were to delete that post, it's not going to do anything to the comments. Those will be retained. So take a look. Now, to keep myself from having to re-enter this record, I'm going to right-click and choose Copy as SQL Insert. Okay. So I will hit Delete or Backspace to delete the post, and you'll see there is no constraint.

Okay. So I will hit Delete or Backspace to delete the post, and you'll see there is no constraint there. So this Comment remains, even though it's associated with a Post that does not exist. So once again, we've screwed up the integrity of our database, and things like this can be difficult and annoying to solve down the line. Now, you already know from previous episodes that the solution is to set up a foreign key constraint. Here's how to do that in your Laravel migration. We'll say right down here, the foreign key post_id.

Here's how to do that in your Laravel migration. We'll say right down here, the foreign key post_id. What does that point to? Let's set it up. That references the ID column on the post table. And we've decided that if you were to delete that post, we should cascade and delete all comments associated with it. All right. So let's give this one more try from scratch. I'll go back to SQL Pro.

So let's give this one more try from scratch. I'll go back to SQL Pro. I'll re-enter that query to build up a Post. So now we can see it there. And then all I have to do is one more time set this up. So now, if I were to delete this Post, it'll cascade and delete the comments associated with it. So now if I take a look here, refresh, that comment is gone. And again, on the comments table, you can review that by going to the Relations tab, and there is our foreign key.

And again, on the comments table, you can review that by going to the Relations tab, and there is our foreign key. Now another option is to just stick with the defaults here. So take a look at this. We're going to run it one more time. And now, if I rerun this query to build up a single post, and then one last time, we set up a comment for it. Next, we now have a visual that there is a relationship here. But also notice, if I try to delete the post, it simply won't let me. So if I try to run it, not going to work.

But also notice, if I try to delete the Post, it simply won't let me. So if I try to run it, not going to work. And again, that's specifically because of the restrict clause, or no action, as we talked about before. All right, let's move on in the next episode.