Sign up to access "Eloquent Relationships By Example" right now.

So this is going to be very simple, but it's going to give you a good understanding of the problem, how to solve it. And then we can dive into some more advanced egoloading a little bit later. OK, so let's go over to our web routes where we're actually outputting this data just here. And we know that we're grabbing the posts, grabbing all posts and just passing them down.

What we want to do at the point that we get the posts is think to ourselves, what additional data does this post use? Well, we know that over on the post, we're actually accessing the user. This is the problem here. When we access this, even if we access it like a property that brings the model back, this is performing an additional query.

So what we want to do is upfront load all of the potential users for the posts that we are getting into one query and then go ahead and just use them. So this sounds a lot more complicated than it is. What we actually want to do, probably the first thing that we want to do here, doesn't matter which order you do this in, is we want to use the with method. And the with method allows you to define the relationships like user that you want to load up front, be kept in memory and then used as we iterate through these posts and access each of the users.

So we want to say, well, for every single post, we want to load in all the potential users or user in this case to go ahead and use them when we need them. So just with that very, very simple change, let's head over to here and see what's different. So I'm going to give this a refresh and you can now see we're down to two queries. Now, you might be thinking, well, surely this could be done in one query.

Well, the difference here is we now do not have an n plus one problem. If we were to add a new post to this, even with a completely different user, it would not go ahead and execute an additional query. What it would do is it would add this in where it's loading in all of the potential users that we have here, which are three users. And then behind the scenes, it's piecing these together with each of the posts with that data.

So for every single iteration, it's using data in memory rather than performing an additional SQL query. Let's just demonstrate that by going over to the database and creating out another user here. In fact, we could do that in Tinker. So let's say PHP Artisan and Tinker.

And let's go ahead and create just one more user. OK, so now that we have another user, let's go and assign another post to user ID of four. So let's go ahead and assign that and another one and save this out, head back over. And now we still have two queries, despite the fact we have an additional post and additional user.

All that's happened behind the scenes is this one query is now pulling in this user just in one query and again is attaching it. So we can go ahead and still output that data, but not perform an additional query. So for every project you build, I'd always recommend pulling in Laravel Debug Bar so you can see the query count that you've got. This will also tell you if you have any duplicate queries.

So, for example, let's just bring that back to the point where we were not eager loading. And get rid of this. And then let's go over and give that a refresh. And you can see here six of which were duplicated.

So you can click to show only the duplicated ones. And if all of these look very similar, you pretty much know you have an N plus one problem. So that could be really useful to pull this into every project. This is the most basic form of eager loading where we don't have any kind of advanced relationships.

We don't have any nested relationships or anything like that. But we will cover that in the rest of the course. But just doing that is going to increase the performance of your application, decrease the memory usage. And it's a really good habit to get into monitoring your queries so you can eager load that data in.