Relaciones polimórficas en Laravel 13: una tabla para muchos dueños

Tarde o temprano te topas con el mismo problema: los comentarios sirven para las publicaciones y para los videos. Las etiquetas valen para los artículos y para los productos. Una imagen puede pertenecer a un usuario o a una publicación. La reacción instintiva es duplicar tablas —post_comments, video_comments— y con ellas duplicar modelos, validaciones y consultas. Las relaciones polimórficas son la respuesta de Eloquent a ese picor: una sola tabla que puede pertenecer a varios modelos distintos, sin repetir esquema. Vamos a ver qué son a nivel de base de datos, cómo las modela Laravel 13 y —tan importante como lo anterior— cuándo es mejor no usarlas.

Qué es una tabla polimórfica

Olvidémonos de Laravel por un momento y quedémonos en la base de datos. Una relación normal usa una clave foránea: la columna post_id de la tabla comments apunta siempre a la tabla posts. El destino es fijo, y el motor lo garantiza con una restricción FOREIGN KEY.

Una relación polimórfica cambia esa regla: el destino ya no es una sola tabla, sino que se decide fila por fila. Para lograrlo no basta con guardar un id; hace falta guardar también a qué tabla pertenece ese id. Por eso una tabla polimórfica lleva dos columnas en lugar de una:

• Una columna de id (commentable_id) — a qué fila apunta.
• Una columna de tipo (commentable_type) — a qué tabla, o mejor dicho, a qué modelo, pertenece esa fila.

Ese par (tipo, id) es lo que hace la magia. Una misma fila de comments puede decir «pertenezco a la publicación 42» y la de al lado «pertenezco al video 7». La tabla es poli-mórfica justamente porque adopta muchas formas de dueño.

Cómo lo modela Laravel 13

Laravel expone el patrón con tres sabores, según la cardinalidad de la relación. La sintaxis apenas cambia entre versiones; lo que sí trae Laravel 13 es PHP 8.3 como mínimo, así que aprovechamos los tipos de retorno en cada método de relación (: MorphTo, : MorphMany), que documentan la intención y ayudan al análisis estático.

// App\Models\Image  (el lado hijo)
use Illuminate\Database\Eloquent\Relations\MorphTo;

class Image extends Model
{
    public function imageable(): MorphTo
    {
        return $this->morphTo();
    }
}

// App\Models\Post y App\Models\User  (los dueños)
use Illuminate\Database\Eloquent\Relations\MorphOne;

class Post extends Model
{
    public function image(): MorphOne
    {
        return $this->morphOne(Image::class, 'imageable');
    }
}

$post  = Post::find(1);
$image = $post->image;          // la imagen de la publicación

$image     = Image::find(1);
$imageable = $image->imageable; // devuelve un Post o un User, según la fila

// App\Models\Comment  (el lado hijo)
use Illuminate\Database\Eloquent\Relations\MorphTo;

class Comment extends Model
{
    public function commentable(): MorphTo
    {
        return $this->morphTo();
    }
}

// Post y Video comparten exactamente la misma definición
use Illuminate\Database\Eloquent\Relations\MorphMany;

class Post extends Model
{
    public function comments(): MorphMany
    {
        return $this->morphMany(Comment::class, 'commentable');
    }
}

$post = Post::find(1);
foreach ($post->comments as $comment) {
    // ...
}

$comment = Comment::find(1);
$dueño   = $comment->commentable; // Post o Video, según commentable_type

// Post y Video  (usan morphToMany)
use Illuminate\Database\Eloquent\Relations\MorphToMany;

class Post extends Model
{
    public function tags(): MorphToMany
    {
        return $this->morphToMany(Tag::class, 'taggable');
    }
}

// App\Models\Tag  (el lado inverso, con morphedByMany)
class Tag extends Model
{
    public function posts(): MorphToMany
    {
        return $this->morphedByMany(Post::class, 'taggable');
    }

    public function videos(): MorphToMany
    {
        return $this->morphedByMany(Video::class, 'taggable');
    }
}

$post = Post::find(1);
$post->tags;   // etiquetas de la publicación

$tag = Tag::find(1);
$tag->posts;   // todo lo etiquetado con este tag, por tipo
$tag->videos;

La migración: dos columnas y un índice

Aquí es donde el patrón se vuelve tangible. Laravel trae ayudantes de migración que crean el par de columnas y —esto importa— el índice compuesto de una sola línea.

Schema::create('comments', function (Blueprint $table) {
    $table->id();
    $table->text('body');
    $table->morphs('commentable'); // _id + _type + índice compuesto
    $table->timestamps();
});

$table->nullableMorphs('commentable'); // permite NULL
$table->uuidMorphs('commentable');     // _id como UUID
$table->ulidMorphs('commentable');     // _id como ULID

Schema::create('taggables', function (Blueprint $table) {
    $table->foreignId('tag_id')->constrained()->cascadeOnDelete();
    $table->morphs('taggable'); // taggable_id + taggable_type
});

El morph map: no encadenes tu base de datos a tu namespace

Por defecto, commentable_type guarda el nombre completo de la clase: la cadena literal App\Models\Post. Funciona, pero acopla tus datos a la estructura de tu código: el día que muevas Post a otro namespace o renombres el modelo, todas las filas históricas quedan apuntando a una clase que ya no existe.

La solución es el morph map: un diccionario que traduce alias cortos y estables a clases. Lo declaras una vez, en el boot de AppServiceProvider:

use Illuminate\Database\Eloquent\Relations\Relation;

public function boot(): void
{
    Relation::enforceMorphMap([
        'post'  => \App\Models\Post::class,
        'video' => \App\Models\Video::class,
    ]);
}

A partir de ahí, la columna guarda 'post' en lugar de App\Models\Post. Más corto, más legible en la base de datos y —lo esencial— desacoplado de tu namespace: reorganiza el código cuanto quieras, que las filas siguen siendo válidas.

El problema N+1 y cómo esquivarlo

Las relaciones polimórficas son terreno fértil para el temido N+1: recorres 50 comentarios y, si accedes a $comment->commentable dentro del bucle sin precargarlo, disparas 50 consultas extra. La carga ansiosa (eager loading) lo resuelve, pero el lado morphTo tiene un matiz: como cada fila puede apuntar a un modelo distinto, Laravel agrupa por tipo y lanza una consulta por cada tipo presente.

// Precarga el dueño de cada comentario en el mínimo de consultas
$comments = Comment::with('commentable')->get();

Cuando además necesitas relaciones anidadas del dueño —los comentarios de la publicación, las etiquetas del video— usa morphWith dentro de la restricción, indicando qué cargar por tipo:

use Illuminate\Database\Eloquent\Relations\MorphTo;

$activities = ActivityFeed::with(['parentable' => function (MorphTo $morphTo) {
    $morphTo->morphWith([
        Post::class  => ['comments'],
        Video::class => ['tags'],
    ]);
}])->get();

Y si quieres blindar el lado morphMany contra el N+1 desde la propia definición, Laravel trae chaperone(), que reasigna a cada hijo su padre ya cargado:

public function comments(): MorphMany
{
    return $this->morphMany(Comment::class, 'commentable')->chaperone();
}

use Illuminate\Database\Eloquent\Builder;

$comments = Comment::whereHasMorph(
    'commentable',
    [Post::class, Video::class],
    fn (Builder $query) => $query->where('title', 'like', 'code%'),
)->get();

El modelo físico y el recorrido en Laravel

Con la teoría en la mano, dos diagramas terminan de aterrizarla. El primero es el modelo físico: cómo se ven realmente las tablas. Fíjate en que las flechas hacia los padres son punteadas —representan el par (tipo, id), no una clave foránea del motor.

El segundo muestra el recorrido dentro de Laravel cuando pides $comment->commentable: del controlador al modelo, del modelo a MorphTo, y de ahí al morph map que traduce el _type a la clase correcta antes de consultar la tabla.

Cuándo NO usar una tabla polimórfica

Aquí es donde separo el tutorial del criterio, porque este patrón tiene detractores con argumentos serios. En su libro SQL Antipatterns, Bill Karwin dedica un capítulo entero a las asociaciones polimórficas y las clasifica como un antipatrón a nivel de base de datos, por la razón que ya adelantamos: rompen la integridad referencial. Al no haber una clave foránea real, nada en el motor impide que quede un commentable_id apuntando a una publicación que ya se borró —un huérfano silencioso.

No es para asustarse ni para prohibirlas; es para elegir con los ojos abiertos.

Cierre

Las relaciones polimórficas no son magia ni pecado: son un intercambio deliberado. Cambias la garantía de integridad del motor por una flexibilidad enorme de modelado, y a cambio de esas dos columnas humildes —_type y _id— dejas de duplicar tablas cada vez que una funcionalidad transversal aparece. Laravel 13 las expone con una API limpia y tipada; la parte difícil no es escribir morphMany, sino saber cuándo el problema pide esta herramienta y cuándo pide una clave foránea de toda la vida. Ahora tienes ambas cosas.

Fuentes

• Eloquent: Relationships — Polymorphic Relationships (documentación oficial de Laravel)
• Laravel 13 — What's new (Laravel News)
• Bill Karwin, SQL Antipatterns, cap. 7: «Polymorphic Associations» (O'Reilly)
• Polymorphic relationships in Laravel and their use cases (LogRocket Blog)