Discuss Your ProjectGet in Touch

What Is Laravel Eloquent?

Laravel Eloquent is the object-relational mapper (ORM) built into the Laravel framework. It lets developers work with database records as PHP objects: each table has a matching model, such as Property for the properties table, and the model is used to find, create, update and delete records without writing SQL by hand for every query.

How Eloquent works

A database stores information in tables of rows and columns. Application code thinks in things: a landlord, a property, a viewing. An ORM connects the two.

In Eloquent, a developer creates a model class for each table. By the convention described in the Eloquent documentation, the table name is the model’s name in the plural and in lower case, with underscores between words: a Flight model stores its records in a flights table, and an AirTrafficController model in air_traffic_controllers. From then on, the model does the database work.

Take a letting agency whose website lets applicants book viewings. To show one negotiator’s viewings for today, in time order, a developer writes:

$viewings = Viewing::where('negotiator_id', $negotiator->id)
    ->whereDate('starts_at', today())
    ->orderBy('starts_at')
    ->get();

And to save a viewing booked through the website form:

Viewing::create([
    'property_id' => $property->id,
    'applicant_id' => $applicant->id,
    'starts_at' => $request->starts_at,
]);

For create to accept these fields, the model has to list them as fillable. That safeguard stops a visitor from adding extra fields to a form to change data they should not touch, such as a negotiator’s commission or an account role. Eloquent then turns each of these calls into the right SQL for the database the project uses.

Relationships between tables

Real data is connected. A landlord has many properties, a property has many viewings, a viewing belongs to an applicant and a negotiator. Eloquent describes these links once, in the models, and then lets developers move between them in code, such as $landlord->properties or $viewing->negotiator.

The relationships documentation lists the types it supports, including one to one, one to many and many to many, as well as polymorphic relationships, where one table can belong to several others. Notes that staff can attach to properties, landlords and applicants alike are a typical example of a polymorphic relationship.

The N+1 query problem: a common performance mistake

Relationships are loaded only when they are first used. That is convenient, and it hides a trap. If a page lists 25 books and shows each book’s author, a naive loop runs 26 queries: one for the books and one more for every author. Laravel’s documentation on Eloquent relationships calls this the “N + 1” query problem.

The fix is eager loading: telling Eloquent in advance which related records to fetch.

$books = Book::with('author')->get();

That brings the same page down to two queries. On a small site the difference is invisible. On an admin screen listing a thousand orders with customers, products and delivery addresses, it can be the difference between a page that loads at once and one that times out. When a Laravel site slows down as its data grows, unplanned queries like these are one of the first things a developer checks.

Why Eloquent matters to a business

  • Readable code. Viewing::where(…) reads close to plain English, which makes the system easier to understand for the next developer and cheaper to maintain.
  • Protection against SQL injection. Eloquent builds its queries through Laravel’s query builder, which uses PDO parameter binding to protect the application against SQL injection attacks. The protection holds as long as developers do not pass raw user input into the parts of a query that bindings cannot cover, such as column names.
  • A data model that grows with the business. Adding property maintenance requests or a second office usually means adding tables and relationships. With models and migrations, those changes are written as code, tested and applied the same way on every copy of the site. Migrations are run with Artisan, Laravel’s command line tool.

The most expensive data mistakes happen before any code is written, in how the tables and relationships are planned. That is why the data structure belongs in the technical specification of a custom project, agreed before the build starts.

How we use Eloquent on projects

Eloquent is part of every Laravel project we build. On Laravel development projects, you own the code, content and accounts, and we provide documentation of the custom parts, including the data structure.

FAQ

ORM stands for object-relational mapping. It is a layer of code that translates between the tables of a relational database and the objects a program works with. Eloquent is Laravel’s ORM; other frameworks have their own, such as Doctrine in Symfony and the Django ORM in Python.

For most everyday work, Eloquent is quicker to write and easier to maintain. For heavy reports or complex calculations across millions of rows, developers often use Laravel’s query builder or raw SQL for that one query, and keep Eloquent for the rest. Both can live in the same project.

Not out of the box. According to the Laravel database documentation, MongoDB support comes through the mongodb/laravel-mongodb package, which is maintained by MongoDB itself. Laravel’s first-party support covers MariaDB, MySQL, PostgreSQL, SQLite and SQL Server.

Yes. Eloquent is part of the Illuminate Database component, which its README describes as a full database toolkit for PHP that can be configured for use outside the Laravel framework. In practice, almost all Eloquent code lives in Laravel applications.

Need a system built around your own data, from bookings to orders? Describe what you store and how it connects, and we will suggest a sensible structure.