Laravel con MySQL: conexión, migraciones, Eloquent y consultas

Laravel no crea automáticamente una buena base de datos

El framework facilita muchísimo la persistencia, pero las decisiones importantes siguen siendo tuyas.

Debes definir correctamente:

Una mala estructura continuará siendo una mala estructura aunque utilices Eloquent.

Si cambias la configuración y Laravel sigue usando valores anteriores, revisa la caché de configuración

En determinados entornos, la configuración puede haber sido almacenada para mejorar el arranque de la aplicación.

Durante desarrollo puede ser útil limpiar esa configuración cuando cambias variables relacionadas con la conexión.

php artisan config:clear

Si la aplicación continúa sin conectarse, revisa también:

Elige tipos de datos según lo que representa cada valor

No todas las columnas deberían ser strings simplemente porque resulta cómodo.

Laravel permite expresar distintos tipos dentro de las migraciones.

Texto

$table->string('nombre', 150);

Booleano

$table->boolean('activo')
    ->default(true);

Decimal

$table->decimal(
    'precio',
    12,
    2
);

El diseño debería reflejar la semántica del dato y las operaciones que necesitarás realizar con él.

Las relaciones deberían existir también en la base de datos, no solamente en Eloquent

Supongamos que un pedido pertenece a un usuario.

La tabla pedidos puede almacenar una referencia al usuario.

<?php

$table->foreignId('usuario_id')
    ->constrained('usuarios');

Conceptualmente:

usuarios
   │
   │ id
   ↓
pedidos.usuario_id

Esto ayuda a preservar integridad entre registros.

Piensa también qué debería ocurrir al eliminar el registro padre

Según el dominio, podrías necesitar:

restringir, mantener, establecer null o eliminar registros relacionados.

Varias columnas pueden formar parte del mismo patrón de búsqueda

Imagina que una aplicación consulta repetidamente pedidos por:

usuario y estado.

Podría existir un caso para evaluar un índice compuesto.

$table->index([
    'usuario_id',
    'estado'
]);

Pero para diseñarlo correctamente necesitas observar cómo consultas realmente los datos.

El orden y composición de un índice importan.

Por eso, cuando la optimización empieza a ser relevante, conviene analizar la consulta y el plan que utiliza MySQL.

Laravel puede realizar las cuatro operaciones básicas sobre MySQL mediante Eloquent

Crear

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

Leer

$producto = Producto::findOrFail($id);

Actualizar

$producto->update([
    'precio' => 189990
]);

Eliminar

$producto->delete();

Valida antes de enviar información a MySQL

Una creación segura no debería comenzar con:

Producto::create(
    $request->all()
);

Es preferible definir qué campos espera la operación.

$datos = $request->validate([
    'nombre' => [
        'required',
        'string',
        'max:150'
    ],
    'sku' => [
        'required',
        'string',
        'max:100'
    ],
    'precio' => [
        'required',
        'numeric',
        'min:0'
    ]
]);

$producto = Producto::create($datos);

La validación comprueba la forma del dato.

Las reglas de negocio pueden necesitar comprobaciones adicionales.

Una relación cómoda puede provocar decenas o cientos de consultas

Este código parece sencillo:

$pedidos = Pedido::all();

foreach ($pedidos as $pedido) {

    echo $pedido->usuario->nombre;

}

Si cada acceso al usuario dispara una consulta adicional, el número de operaciones puede crecer rápidamente.

Eager loading

$pedidos = Pedido::query()
    ->with('usuario')
    ->get();

Ahora indicas que la relación será necesaria durante esa consulta.

No recuperes toda una tabla para mostrar veinte registros

Una tienda podría tener decenas o cientos de miles de productos.

Esto:

$productos = Producto::all();

no debería ser la estrategia por defecto para una interfaz paginada.

Puedes recuperar un conjunto limitado.

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

La paginación reduce datos transferidos y memoria utilizada por la aplicación.

Dos usuarios pueden intentar modificar los mismos datos al mismo tiempo

Esto aparece en situaciones como:

Una aplicación que primero consulta stock y después lo descuenta sin considerar concurrencia puede producir resultados inconsistentes.

Las transacciones pueden formar parte de la solución

Y determinadas operaciones pueden necesitar bloqueos o estrategias específicas de concurrencia.

Factories pueden generar registros útiles para testing y desarrollo

Probar una aplicación con solamente dos registros puede esconder problemas que aparecen con volúmenes mayores.

Los datos generados pueden ayudarte a probar:

Esto resulta mucho más útil que crear manualmente cientos de filas.

Poder reconstruir una base de desarrollo reduce configuraciones manuales difíciles de repetir

Una de las ventajas de migraciones y seeders es que puedes describir gran parte del estado inicial necesario por la aplicación.

Esto ayuda cuando:

Recupera solamente las columnas que necesita el caso de uso cuando eso aporte valor

Un listado quizá solo necesita:

ID, nombre, precio y estado.

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

Esto puede reducir datos innecesarios cuando una tabla contiene columnas grandes.

Tampoco optimices cada consulta prematuramente

La optimización debería responder a necesidades reales y mediciones, no solamente a reglas aplicadas mecánicamente.

Usar Laravel no significa que SQL directo esté prohibido

Determinados:

pueden resultar más claros usando Query Builder o expresiones SQL controladas.

El objetivo no es forzar toda consulta a parecer un model.

El objetivo es mantener código legible, seguro y eficiente.

No mezcles queries, HTML y reglas de negocio dentro del mismo controller

Laravel permite realizar una consulta desde prácticamente cualquier lugar de la aplicación.

Eso no significa que sea una buena idea hacerlo sin una estructura.

Un controller debería evitar convertirse en algo como:

Request
↓
Validación
↓
20 consultas
↓
Reglas de negocio
↓
Pago
↓
Email
↓
HTML
↓
Response

Cuando el proceso crece, separa responsabilidades con criterio.

Las migraciones forman parte del despliegue, pero deben ejecutarse con criterio

Un cambio sencillo en desarrollo puede ser mucho más delicado sobre una tabla con millones de filas.

Antes de modificar la base de producción, considera:

Qué evitar al trabajar con Laravel y MySQL

Continúa profundizando en Laravel y bases de datos