Respuesta.

Procedimientos almacenados (stored procedures) — bloques programables que se llaman explícitamente y pueden aceptar parámetros, ejecutar lógica empresarial compleja, manejar transacciones, devolver conjuntos de datos o parámetros de salida.

Triggers (triggers) — objetos especiales que se activan "automáticamente" ante eventos de cambio de datos (INSERT, UPDATE, DELETE), asegurando la ejecución transparente de la lógica dada en ciertas acciones sobre la tabla.

Cuándo usar procedimientos

• Se necesita procesar grandes volúmenes de datos.
• Se requiere control explícito de transacciones.
• Se necesita devolver un resultado o varios conjuntos de datos.

Cuándo usar triggers

• Se requiere garantizar verificaciones o actualizaciones implícitas ante cualquier cambio de datos (por ejemplo, auditoría).
• Se necesita implementar verificaciones de integridad a través de todo el proceso.

Ejemplo de código

Procedimiento almacenado:

CREATE PROCEDURE UpdateProductPrice
  @ProductID int, @NewPrice money
AS
BEGIN
  UPDATE Products SET Price = @NewPrice WHERE ProductID = @ProductID;
END

Trigger:

CREATE TRIGGER trg_ProductsPriceChange
ON Products
AFTER UPDATE
AS
BEGIN
  INSERT INTO PriceAuditLog(ProductID, OldPrice, NewPrice, ChangeDate)
  SELECT i.ProductID, d.Price, i.Price, GETDATE()
  FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID
  WHERE i.Price <> d.Price
END

Pregunta capciosa.

P: ¿Se puede determinar el orden de ejecución de varios triggers AFTER en una misma tabla en SQL Server usando medios estándar?

R: No, el estándar SQL no garantiza el orden de activación de los triggers AFTER en una misma dirección en una tabla. Si el orden es importante, deben combinarse en uno solo.

Ejemplos de errores reales debido al desconocimiento de los matices del tema.

---

Historia

En la solución CRM para soportar la funcionalidad de historial de cambios se usaron triggers. Debido a la alta carga de actualizaciones masivas, los registros en el log llegaban con retraso, bloqueando las operaciones "en vivo", lo que causó una temporal indisponibilidad del servicio.

---

Historia

Un desarrollador creó la lógica de verificación de datos no en el procedimiento, sino en el trigger, esperando que el cambio fuera visible para el usuario de inmediato. Olvidando que el trigger es "transparente", se encontró con que la lógica empresarial se volvió poco clara ("magia") y era difícil de depurar.

---

Historia

Importante: A menudo, se llama a un procedimiento dentro de un trigger, o se activa un trigger desde un procedimiento, lo que lleva a recursión y supera el límite de anidamiento; por ejemplo, una inserción automática provoca la reactivación del trigger a través de un procedimiento relacionado.