Mejores prácticas para Triggers
Los triggers son herramientas potentes. Prefiere la lógica de la aplicación a menos que la base de datos deba ser la última línea de defensa.
Cómo usar esta lista
- Requiere una nota de diseño en la migración para nuevos triggers.
- Realiza pruebas de carga en la ruta de escritura con los triggers habilitados.
A - Alcance
- Cuerpos de triggers pequeños. Delega a funciones pero mantén la lógica mínima.
- Cláusula WHEN para limitar ejecuciones. Omite actualizaciones que no hagan nada.
- Evita cadenas a través de muchas tablas. El grafo de triggers es difícil de depurar.
B - Rendimiento
- Triggers de sentencia para operaciones masivas. Transfiere tablas.
- No realices llamadas remotas en triggers. Usa el patrón outbox.
- Deshabilita durante el mantenimiento masivo. Vuelve a habilitar en el mismo ticket de cambio.
C - Gobernanza
- Nombra los triggers de forma consistente.
tr_<tabla>_<acción>_<propósito>. - Pruebas para el comportamiento del trigger. Fixtures de reversión.
- Planifica la ruta de eliminación. Los triggers sobreviven a las aplicaciones si se olvidan.
Preguntas frecuentes
¿El trigger updated_at sigue estando bien?
Sí, es común y pequeño; la alternativa de columnas GENERATED en flujos de trabajo de PG 18.
Relacionado
- Conceptos básicos de Triggers - sintaxis
- Cuándo no usar Triggers - alternativas
Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.