If a user has exactly one profile, then what would be the relationship between a user and posts? Well, let's talk it out. Does a user have exactly one post? No, they could create as many blog posts as they want. But what about the inverse? Does a post belong to many users? Maybe, but in our situation, a post belongs to exactly one user. Over here, we have a very common example of a one-to-many relationship. One user can have many posts.

Over here, we have a very common example of a one-to-many relationship. One User can have many Posts. However, you'll notice from our example many episodes ago, there is no relationship between a Post and a User. Sounds like we need to update that. User ID, and like always, it will be unsigned and not nullable. OK, now I can say, the User with an ID of one has any kind of blog post they need. There we go. So now I could say, give me all of the Posts that were created by the User with an ID of one. Now, maybe you're going to iterate over these and include information about the User.

So now I could say, give me all of the Posts that were created by the User with an ID of 1. Now, maybe you're going to iterate over these and include information about the User. Maybe, if nothing else, you want the User's name. OK, let's do a join. Join the users table on the condition that the User's ID matches up with the post's ID. All right, so now for every single Post, I have information about the name. But I also have lots of other information about the User that I don't care about. So, when you can, try to be explicit about what you're selecting. In our case, I want the title of the Post, the body, maybe the timestamps. Or really, maybe just the published_at.

In our case, I want the title of the post, the body, maybe the timestamps. Or really, maybe just the published_at. And, well, maybe we need the ID, just in case. And then finally, the user's name. Roderick Smith created this post. And don't forget, if you ever want to alias it, if name isn't quite what we want in this case, let's alias it to author. All right, now let's switch over to Laravel. So, we already have a migration to whip up this post table. So, we'll just stick with the Eloquent end.

So, we already have a migration to whip up this post table. So, we'll just stick with the Eloquent end. If I switch back, my User model has a relationship to posts. And it's not a hasOne relationship like before, it is a hasMany relationship. And for the inverse on the Post model, a Post belongs to a User. Or you might even say author, if you'd rather access it in that way. A Post belongs to a User. Now, in this case though, Eloquent is going to use the method name to figure out what the foreign key should be. So, it's going to look for an author_id foreign key.

to figure out what the foreign key should be. So, it's going to look for an author_id foreign key. And that's not what we have. So, I need to be explicit here that it's actually called user_id. I just want to call it author on the php end. All right, so once again, I will disable mass assignment protection. And if I boot up php artisan tinker, and we'll fetch our User and create a new Post. Post::create( ) , and we need a title and a body. And there we go. So, if I now switch back to SQL Pro and give this a refresh,

And there we go. So, if I now switch back to SQL Pro and give this a refresh, we've now used Laravel and Eloquent to create this record. Which means, if I switch back, I can now say give me all the Posts that were created by the current User. And by the way, notice that we get a collection in this case. For a hasOne relationship, there's no need to return a collection, because there's only one record. But for a hasMany relationship, there are multiple records. So, that's why we have an array here.

But for a hasMany relationship, there are multiple records. So, that's why we have an array here. We have a collection of Posts that belong to the User. And the same will be true in reverse. If I have a Post, get the most recent one, there it is. Let's find the author of the Post. There we go. And that, in a nutshell, is a one-to-many relationship.