Eloquent en Laravel: models, relaciones, CRUD y consultas

Un model Eloquent representa una entidad persistida

Supongamos que tenemos una tabla llamada:

productos

Podemos representar esos datos mediante un model:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

final class Producto extends Model
{
    protected $fillable = [
        'nombre',
        'precio',
        'activo'
    ];
}

A partir de ahí, la clase puede utilizarse para realizar operaciones sobre esos registros.

El model no debería entenderse simplemente como “una tabla convertida en clase”

Puede representar relaciones, reglas relacionadas con persistencia, transformaciones y comportamiento asociado a esa entidad.

Pero tampoco deberías convertir cada model en una clase gigantesca que contenga toda la lógica del sistema.

Crear registros con Eloquent

Podemos insertar un producto utilizando el model.

$producto = Producto::create([
    'nombre' => 'Monitor 27"',
    'precio' => 199990,
    'activo' => true
]);

El resultado es un objeto que representa el registro creado.

También puedes instanciar el model

$producto = new Producto();

$producto->nombre = 'Teclado mecánico';
$producto->precio = 69990;
$producto->activo = true;

$producto->save();

Ambos enfoques pueden ser válidos.

Lo importante es comprender qué datos estás permitiendo persistir.

Las relaciones son una de las partes más importantes de Eloquent

Las aplicaciones reales no suelen trabajar con tablas aisladas.

Un usuario puede tener pedidos.

Un pedido puede tener productos.

Un artículo puede pertenecer a una categoría.

Eloquent permite expresar estas asociaciones mediante métodos en los models.

Usuario
   │
   └── tiene muchos → Pedidos

Pedido
   │
   └── pertenece a → Usuario

Para utilizar correctamente estas relaciones, primero deberías entender primary keys, foreign keys y cardinalidad en una base de datos relacional.

Un pedido puede contener muchos productos y un producto aparecer en muchos pedidos

Este tipo de relación normalmente necesita una tabla intermedia.

pedidos
   ↓
pedido_producto
   ↑
productos

Dentro del model Pedido:

<?php

public function productos()
{
    return $this->belongsToMany(
        Producto::class
    );
}

La tabla intermedia también puede almacenar datos propios de la relación.

Por ejemplo:

Esto demuestra que una tabla pivote no es solamente una formalidad técnica: puede representar información propia de la relación.

Acceder a una relación puede ejecutar una consulta adicional

Considera:

$pedidos = Pedido::all();

foreach ($pedidos as $pedido) {

    echo $pedido->usuario->nombre;

}

Visualmente, el código parece simple.

Pero si cada acceso a:

$pedido->usuario

provoca una consulta, puedes generar muchísimas operaciones innecesarias.

Aquí aparece uno de los conceptos más importantes al trabajar con ORM.

No siempre necesitas SELECT *

Si una pantalla solamente necesita:

ID, nombre y precio, puedes expresar esa necesidad.

$productos = Producto::query()
    ->select([
        'id',
        'nombre',
        'precio'
    ])
    ->where('activo', true)
    ->get();

Esto puede ser especialmente importante cuando las tablas contienen columnas grandes que esa operación no necesita.

La optimización empieza por entender qué necesita realmente la consulta

No por añadir técnicas complejas automáticamente.

Una lista grande no debería cargar todos sus registros en una sola página

Si tienes 100.000 productos, esto:

$productos = Producto::all();

probablemente no representa lo que necesita una interfaz paginada.

Puedes solicitar una cantidad limitada por página.

$productos = Producto::query()
    ->where('activo', true)
    ->orderBy('id')
    ->paginate(20);

Para conjuntos extremadamente grandes y determinados patrones de navegación, existen estrategias alternativas a offsets profundos.

Pero para empezar, lo importante es comprender que paginar también forma parte del diseño de la consulta.

No todas las consultas necesitan convertirse en models completos

Eloquent resulta especialmente útil cuando trabajas con entidades y relaciones.

Pero existen consultas orientadas a reportes, métricas o agregaciones donde un enfoque más directo puede resultar más claro.

Laravel también proporciona Query Builder.

<?php

use Illuminate\Support\Facades\DB;

$ventas = DB::table('pedidos')
    ->selectRaw(
        'DATE(created_at) AS fecha, SUM(total) AS total'
    )
    ->groupByRaw(
        'DATE(created_at)'
    )
    ->get();

Elegir Eloquent no obliga a utilizarlo para absolutamente todo

Utiliza la herramienta que exprese mejor la consulta y su propósito.

Eloquent no puede compensar una base de datos mal indexada

Imagina una consulta que filtra constantemente millones de registros por una columna.

El problema puede estar mucho más relacionado con el diseño de índices que con Eloquent.

Un ORM puede construir la consulta, pero MySQL sigue siendo responsable de ejecutarla.

No indexes todo automáticamente

Los índices aceleran determinados patrones de lectura, pero también ocupan espacio y añaden trabajo en escrituras.

Diseña índices según las consultas reales de la aplicación.

No todos los registros deberían desaparecer físicamente al “eliminarlos”

En determinados sistemas necesitas conservar registros por trazabilidad, historial o recuperación.

Laravel permite trabajar con mecanismos de eliminación lógica cuando el modelo del negocio lo requiere.

Pero no conviertas soft delete en una regla universal

Existen datos que realmente deberían eliminarse y otros que deben conservarse.

Esa decisión pertenece al modelo de negocio y a los requisitos de datos, no únicamente al ORM.

Las consultas y relaciones importantes también deberían probarse

No basta con comprobar que una página “se ve bien”.

Puedes probar comportamientos como:

El objetivo no es probar que Laravel funciona.

Es comprobar que tus reglas y consultas producen el comportamiento que esperas.

En qué orden aprender Eloquent

Eloquent es potente cuando entiendes tanto los objetos PHP como la base de datos que existe debajo