Respuesta

Triggers — objetos especiales de la base de datos que ejecutan automáticamente un determinado código (generalmente en SQL o en lenguajes de extensiones procedimentales, como PL/pgSQL para PostgreSQL) cuando ocurre un evento: INSERT, UPDATE o DELETE en una tabla.

Ventajas:

• Aplicación centralizada de la lógica empresarial y validación de datos.
• Automatización de auditorías (por ejemplo, historial de cambios).

Desventajas:

• Ejecución oculta — no siempre es obvio que se ha ejecutado un trigger.
• Disminución del rendimiento en caso de cambios frecuentes en las tablas.
• Dificultades en la depuración y el debug, riesgo de recursividad (triggers recursivos).
• Migraciones de datos se vuelven más complejas.

Cuándo aplicarlo:

• Auditoría de datos.
• Creación automática de registros relacionados.
• Implementación de control de restricciones, imposibles con medios estándar.

Ejemplo de trigger (PostgreSQL):

CREATE TABLE employee_audit (
  id SERIAL PRIMARY KEY,
  employee_id INT,
  old_salary NUMERIC,
  new_salary NUMERIC,
  changed_at TIMESTAMP
);

CREATE OR REPLACE FUNCTION audit_salary()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.salary <> OLD.salary THEN
    INSERT INTO employee_audit(employee_id, old_salary, new_salary, changed_at)
    VALUES (OLD.id, OLD.salary, NEW.salary, NOW());
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_salary_update
AFTER UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION audit_salary();

Pregunta engañosa

¿Se puede actualizar la misma tabla dentro de un trigger al que está destinado? ¿Qué sucederá?

Respuesta:
Si el trigger está configurado para un evento, digamos, UPDATE de la tabla y dentro de sí mismo ejecuta otro UPDATE de la misma tabla, esto resultará en una recursión infinita (bucle) y terminará con un fallo del comando o un error debido a la profundidad de los triggers. Por lo tanto, siempre controle para que no ocurra recursión, o use opciones que permitan/prohíban llamadas recursivas.

Ejemplo:

-- Esta construcción puede hacer que el trigger entre en bucle:
CREATE OR REPLACE FUNCTION recursive_update()
RETURNS TRIGGER AS $$
BEGIN
  UPDATE employees SET salary = salary * 1.01 WHERE id = NEW.id; -- se activará de nuevo
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

---

Historia

En la CRM contable se implementó un trigger para registrar automáticamente operaciones en un log al modificar la tabla de transacciones. Bajo alta carga, el servicio comenzó a funcionar más lento, y el análisis mostró: el trigger estaba consumiendo mucho tiempo en insertar en el log y no estaba optimizado (por ejemplo, no solo registraba eventos significativos).

---

Historia

En el proyecto de gestión de inventarios se utilizó un trigger BEFORE INSERT para calcular el ID de la posición. Una lógica incorrecta del ID provocaba duplicación de datos, y el error permanecía sin ser detectado durante mucho tiempo, porque funcionaba "en segundo plano".

---

Historia

En la plataforma de RRHH, el trigger realizaba actualizaciones masivas de registros en las tablas padre e hija en cada INSERT. Debido a errores en la lógica del trigger, se generó recursión, lo que bloqueó completamente todas las operaciones en las tablas. Tuvo que desactivarse el trigger y realizar una complicada mitigación de rollback para desbloquear las tablas.