El artículo examina el llamado "arco exclusivo" (exclusive arc), un esquema de bases de datos relacionales empleado para modelar polimorfismo: situaciones en las que una entidad, como un comentario, puede pertenecer a uno solo entre varios tipos de entidades padre (publicaciones o páginas, por ejemplo). El texto, firmado por el creador de la gema activerecord-exclusive-arc, parte de una pregunta clásica en diseño de bases de datos —si este patrón es perjudicial— y la responde con una defensa argumentada.
En primer lugar, repasa la implementación de polimorfismo que popularizó Ruby on Rails con ActiveRecord, basada en columnas commentable_id y commentable_type. Aunque práctica, esa estrategia almacena el nombre de la clase como cadena de texto, lo que impide declarar claves foráneas reales y compromete la integridad referencial: cambiar el nombre de una clase exige actualizar registros manualmente, y la base de datos no puede garantizar que los identificadores sigan siendo válidos.
Como alternativa, el texto presenta el arco exclusivo: una tabla que incluye todas las claves foráneas posibles (post_id, page_id, etc.) acompañadas de una restricción CHECK que asegura que solo una de ellas esté definida por fila. De ese modo se conservan tanto la integridad referencial mediante FOREIGN KEY como la lógica de exclusividad, sin depender de código de aplicación ni de cadenas de texto.
El autor muestra la sintaxis SQL correspondiente en PostgreSQL, explica cómo mapearla a modelos de ActiveRecord con belongs_to opcionales, y presenta la gema activerecord-exclusive-arc, que automatiza la generación de migraciones, restricciones CHECK e índices parciales. Concluye que el arco exclusivo no es un antipatrón, sino una solución pragmática cuando se aprovechan las restricciones del propio motor de base de datos.