Risposta.

Stored procedures — blocchi programmabili che vengono richiamati esplicitamente e possono accettare parametri, eseguire logica di business complessa, gestire transazioni, restituire set di dati o parametri di uscita.

Triggers — oggetti speciali che si attivano automaticamente su eventi di modifica dei dati (INSERT, UPDATE, DELETE), garantendo l'esecuzione trasparente della logica definita in seguito a determinate azioni su una tabella.

Quando utilizzare le procedure

• È necessaria l'elaborazione di grandi volumi di dati.
• È richiesta un'esecuzione esplicita delle transazioni.
• È necessario restituire un risultato o più set di dati.

Quando utilizzare i triggers

• È necessario garantire controlli o aggiornamenti impliciti in caso di modifiche ai dati (ad esempio, auditing).
• È necessario implementare controlli trasversali di integrità.

Esempio di codice

Stored procedure:

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

Domanda insidiosa.

D: È possibile determinare l'ordine di esecuzione di più AFTER-triggers sulla stessa tabella in SQL Server con strumenti standard?

R: No, lo standard SQL non garantisce l'ordine di attivazione degli AFTER-triggers di orientamento simile su una tabella. Se l'ordine è importante, dovrebbero essere combinati in uno.

Esempi di errori reali dovuti alla mancanza di conoscenza delle sfumature del tema.

---

Storia

Nella soluzione CRM per supportare la funzionalità della storia delle modifiche sono stati utilizzati triggers. A causa dell'elevato carico di aggiornamenti di massa, le registrazioni nel log arrivavano con ritardo e bloccavano le operazioni "live", causando una temporanea indisponibilità del servizio.

---

Storia

Uno sviluppatore ha creato la logica di verifica dei dati non nella procedura, ma nel trigger, aspettandosi che le modifiche fossero visibili agli utenti immediatamente. Dimenticando che il trigger è "trasparente", si è trovato di fronte a una logica di business che era poco chiara ("magia") e difficile da fare il debug.

---

Storia

È importante: Spesso una procedura viene richiamata all'interno di un trigger, oppure un trigger da una procedura, il che porta a ricorsione e superamento del limite di nidificazione — ad esempio, un'inserzione automatica può causare la riattivazione del trigger tramite una procedura collegata.