Eloquent basics: models, relationships, and your first queries

Last month, I sat down with a junior developer who was struggling to fetch related data in a Laravel project. They were writing raw SQL joins inside their controllers, effectively bypassing the very engine that makes Laravel so powerful. We spent about two hours refactoring their code, and by the end, they were shocked at how much cleaner their logic became once they embraced the ORM.

Understanding Eloquent models

At its core, Eloquent is an ActiveRecord implementation. Each database table has a corresponding "Model" that you use to interact with that table. You don't need to write SELECT * FROM users anymore. Instead, you define a class that extends Illuminate\Database\Eloquent\Model.

If you've already mastered Laravel routing and controllers: A Beginner's Guide to MVC, you know that your controller shouldn't contain heavy logic. Your models are where you define how your data behaves.

Creating a model is as simple as running an Artisan command:

Bash
php artisan make:model Post

This creates app/Models/Post.php. By default, Laravel assumes your table is named posts. If you named your table differently, you just need to set the $table property on the class. It’s a small detail, but it saves you from "table not found" errors that drive everyone crazy in their first week.

Mastering Eloquent relationships

Once you have your models, you'll inevitably need to connect them. This is where most beginners get stuck, but the syntax is surprisingly readable. Let’s say a User has many Posts.

In your User model, you define the relationship like this:

PHP
public function posts()
{
    return $this->hasMany(Post::class);
}

Now, instead of manually joining tables, you can simply call $user->posts. Laravel handles the foreign key resolution automatically. We've all been tempted to write custom SQL for complex queries, but before you do, check if a relationship method exists. I once wasted about three hours writing a manual join for a simple one-to-many relationship, only to realize I could have done it in one line with hasMany.

Don't overcomplicate it. If you need to scale your logic later, you can always look into designing a clean service layer in Laravel without over-abstraction to keep your controller thin.

Executing your first queries

When it comes to Eloquent basics, querying is the bread and butter of your daily work. You can chain methods to filter your results before you even hit the database.

Here’s how you might fetch the latest five posts from a specific user:

PHP
$posts = Post::where('user_id', $user->id)
             ->latest()
             ->take(5)
             ->get();

The get() method is what actually triggers the database query. If you’re just checking if a record exists, use exists() instead—it's much faster because it stops at the first match.

Common pitfalls to avoid

1. N+1 Query Problem: This happens when you loop through a collection and perform a query for every item. Always use with() to eager load relationships. If you're looping through 100 posts to show the author's name, Post::with('user')->get() will save you from running 101 queries.
2. Mass Assignment: Always define your $fillable or $guarded properties in your model. If you don't, you'll open your app to security vulnerabilities where users can inject data into columns you never intended to be editable.
3. Returning too much data: Just because you can pull the entire user object doesn't mean you should. If you only need the email address, use select('email').

Frequently Asked Questions

Why should I use Eloquent instead of raw SQL? Eloquent protects you from SQL injection attacks by using PDO parameter binding, and it makes your code significantly more readable and maintainable as your application grows.

Is Eloquent slow? For 99% of applications, it's plenty fast. If you're running into performance issues, it's usually because you're fetching too much data or missing indexes in your database, not because of the ORM itself.

When should I use Query Builder instead of Eloquent? Eloquent is perfect for standard CRUD operations. If you're building a massive reporting tool with complex aggregations and window functions, raw SQL or the Query Builder might be more performant and easier to reason about.

I still find myself reaching for the Query Builder when I'm dealing with deeply nested subqueries or weird legacy database schemas. It’s not an "either-or" situation; it’s about picking the right tool for the specific task at hand. Don't be afraid to drop down into SQL if the ORM starts fighting you.