Cuando borras una pregunta en una aplicación con relaciones anidadas, el riesgo es claro: dejar registros sueltos que nadie referencia. La eliminación en cascada en Laravel soluciona ese problema desde el modelo, manteniendo tu controlador limpio y tu base de datos coherente. Esta guía te muestra cómo implementarla paso a paso usando el evento deleting de Eloquent.

¿Qué son los datos huérfanos y por qué importan?

Los datos huérfanos son registros que quedan en tu base de datos sin un padre que los referencie. Si borras una pregunta pero sus comentarios, respuestas y corazones siguen ahí, tu sistema acumula basura silenciosa que tarde o temprano genera errores.

¿Qué es un dato huérfano? Es un registro hijo que sigue existiendo después de que su registro padre fue eliminado. Por ejemplo, un like asociado a una pregunta que ya no existe.

En el ejemplo de la clase, una pregunta puede tener corazones, comentarios y respuestas. A su vez, cada comentario y cada respuesta también pueden tener sus propios corazones y comentarios anidados. Si no haces una limpieza coordinada, terminas con tablas llenas de residuos.

¿Por qué programar la eliminación en cascada en el modelo y no en el controlador?

Podrías escribir toda la lógica de borrado dentro del controlador antes de eliminar la pregunta. Funciona, pero el controlador se infla con código que no le corresponde. La alternativa elegante es usar el método estático boot del modelo y engancharte al evento deleting, que Laravel dispara mientras se está eliminando un registro.

Esto te permite centralizar la lógica donde realmente vive: en el modelo de la entidad. Tu controlador queda limpio y la regla de negocio viaja con la entidad sin importar desde dónde la borres.

¿Cómo se registra el evento deleting en Eloquent?

Dentro del modelo Pregunta, defines un método boot estático que escucha cuándo se está eliminando una instancia. Mientras ocurre ese proceso, ejecutas las limpiezas necesarias antes de que el registro principal desaparezca.

La lógica sigue este orden:

• Eliminar los corazones asignados directamente a la pregunta.
• Recorrer cada comentario de la pregunta, borrar sus corazones y luego el comentario.
• Recorrer cada respuesta, borrar sus corazones, recorrer los comentarios de esa respuesta, borrar los corazones de esos comentarios y finalmente los comentarios.

php protected static function boot() { parent::boot();

static::deleting(function ($pregunta) {
    $pregunta->corazones()->delete();

    $pregunta->comentarios()->get()->each(function ($comentario) {
        $comentario->corazones()->delete();
        $comentario->delete();
    });

    $pregunta->respuestas()->get()->each(function ($respuesta) {
        $respuesta->corazones()->delete();

        $respuesta->comentarios()->get()->each(function ($comentario) {
            $comentario->corazones()->delete();
            $comentario->delete();
        });
    });
});

}

¿Cuándo dejar que la base de datos haga el trabajo?

No todo lo tienes que borrar manualmente. En la migración de respuestas existe una relación con onDelete('cascade'), lo que significa que la propia base de datos elimina las respuestas asociadas cuando borras la pregunta. Por eso el código no necesita un delete() explícito sobre la respuesta: la restricción de la foreign key lo resuelve.

¿Qué hace onDelete cascade en una migración? Le dice a la base de datos que cuando se elimine el registro padre, también elimine automáticamente todos los registros hijos relacionados por esa foreign key.

La diferencia es importante: los corazones y comentarios anidados sí requieren limpieza manual desde el modelo, mientras que las respuestas se eliminan por la restricción declarada en la migración. Combinar ambos enfoques es lo que hace robusto al sistema.

¿Cómo verificar que la limpieza funciona?

El flujo de prueba que se mostró parte de un estado conocido. Tras ejecutar php artisan migrate:fresh y volver a sembrar los seeders, los datos quedan así:

• 30 preguntas.
• 200 comentarios.
• 50 respuestas.
• 0 corazones asignados al inicio.

Luego asignas un corazón a una pregunta, a un comentario, a una respuesta y a otro comentario. Eliminas la pregunta y revisas la tabla de corazones: ya no quedan registros vinculados. La tabla de preguntas pasa de 30 a 29, y todo lo asociado desaparece sin residuos.

¿Qué diferencia un proyecto bien hecho de uno descuidado?

La integridad de los datos. Un sistema que arrastra registros huérfanos termina mostrando likes fantasma, comentarios que apuntan a la nada o consultas que devuelven errores inesperados. Implementar la eliminación en cascada a nivel de modelo y de base de datos al mismo tiempo es una de esas decisiones que no se ven, pero que sostienen la calidad del producto a largo plazo.

Ahora el sistema maneja el borrado de forma automática y segura. Aplica esta misma estructura a tu blog: identifica qué entidades tienen hijos anidados, decide qué resuelve la base de datos con cascade y qué necesitas limpiar desde el evento deleting del modelo. ¿Cómo vas a estructurar tus relaciones para evitar datos huérfanos en tu próximo proyecto?