¿Realmente necesitas claves foráneas?

Artículo original ↗ Discusión en Hacker News ↗

La cuestión de si imponer restricciones de clave foránea en bases de datos relacionales enfrenta la integridad de los datos y la mantenibilidad a largo plazo contra el rendimiento de escritura, la flexibilidad del sharding y la complejidad de las migraciones. Muchos ingenieros sostienen que las restricciones deberían ser la opción por defecto porque evitan errores sutiles, documentan el modelo de datos y protegen datos que sobrevivirán a cualquier aplicación individual, mientras que otros señalan grandes despliegues de MySQL y arquitecturas especializadas donde se eliminan las restricciones y la integridad se aplica en el código de la aplicación. El intercambio destaca que las claves foráneas rara vez son un cuello de botella a escalas típicas, y que optar por omitirlas de forma segura exige mucha disciplina, buenas herramientas y una comprensión clara de las compensaciones.

Postura general sobre las restricciones de clave foránea

  • La gran mayoría opina: usa restricciones de clave foránea (FK) por defecto en cualquier sistema no trivial y de larga duración.
  • Evitan datos corruptos o huérfanos, exponen errores de la aplicación pronto y hacen más segura la refactorización.
  • Varias experiencias con grandes sistemas heredados de MySQL / de cientos de tablas sin FKs se convierten en pesadillas de “podredumbre de datos”, que requieren scripts de limpieza frágiles y conocimiento institucional.

Integridad de datos, seguridad y documentación

  • Las FKs se presentan como tipos, cinturones de seguridad o memoria protegida: puedes programar sin ellas, pero detectan muchos errores de forma barata.
  • Con restricciones fuertes, los equipos pueden asumir “si está en la base de datos, es válido”, tratando la base de datos como una fortaleza.
  • Las FKs proporcionan documentación viva del modelo de datos; la ausencia de FKs dificulta entender las relaciones o incluso saber si una columna es una referencia o no.

Rendimiento, escala y cuándo considerar eliminar FKs

  • Los críticos argumentan que las FKs ralentizan las cargas intensivas de escritura/borrado, complican el sharding y los cambios de esquema en línea (especialmente en MySQL) y añaden contención de bloqueos.
  • Otros responden que:
    • La mayoría de las apps nunca alcanzan una escala en la que esto importe.
    • El coste de la integridad se paga en algún sitio; mover las comprobaciones al código de la aplicación no las hace gratis y expone a condiciones de carrera.
    • El procesamiento por lotes, las restricciones diferidas y el ajuste fino suelen mitigar los problemas de rendimiento.
  • Algunas plataformas de altísima escala o muy complejas implementan capas de integridad personalizadas en lugar de FKs nativas, pero esto se presenta como una elección avanzada y especializada.

Aplicación vs base de datos para la aplicación de reglas

  • Un bando: la integridad puede imponerse en la capa de aplicación o de servicio, especialmente si solo hay un escritor y un control de acceso estricto; las FKs son opcionales.
  • El bando contrario: varias aplicaciones, acceso ad hoc y la semántica de concurrencia hacen que reproducir en código las garantías de la base de datos sea frágil y propenso a errores.

Borrados suaves y comportamiento de eliminación

  • Combinar borrados suaves con deleted_at y FKs es complicado, especialmente para garantizar que los padres con hijos activos no puedan borrarse suavemente.
  • Enfoques propuestos: borrado suave universal, FKs compuestas que incluyan una marca de “is_deleted”, mover las filas borradas a tablas separadas o tablas de auditoría mediante triggers.

Estrategias de entorno

  • Algunos sugieren activar las FKs solo en dev/test para detectar problemas y desactivarlas en producción para acelerar la ingesta.
  • Esto recibe muchas críticas por ser al revés y arriesgado: la producción, no las pruebas, es donde están los datos que realmente importan.