Trigger

I Trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza una soluzione standard e chi la fornisce, tra clienti e software vendor. Sembrano facili da scrivere, ma scrivere Trigger efficienti non è affatto semplice e quando la loro complessità aumenta, possono presentare effetti collaterali in grado di confondere persino l’autore. Tuttavia, per quanti difetti possano avere, hanno un pregio dannatamente importante: permettono di risolvere problemi che non potrebbero essere gestiti in qualsiasi altro layer applicativo. Quindi, se non potete farne a meno, non vi resta che imparare i trucchi e delle best practices per scriverli e gestirli in modo efficiente.

I più importanti linguaggi di programmazione hanno strumenti di debug integrati direttamente nell’IDE. Il debugger ha tipicamente un’interfaccia grafica che consente di esaminare i valori che assumono le variabili durante l’esecuzione, il flusso del programma (step-by-step) e permette di definire punti di interruzione in corrispondenza dei quali fermare l’esecuzione del programma.

Ogni sviluppatore ama gli strumenti di debug, specialmente quando deve capire perché un programma genera un errore o quando viene effettuato un calcolo errato.

I trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza una soluzione standard e chi la fornisce, tra clienti e software vendor. Sono spesso i primi imputati quando le performance dell’istanza SQL Server o del database degradano. Sembrano facili da scrivere, ma scrivere trigger efficienti non è affatto semplice e quando la loro complessità aumenta, talvolta possono presentare effetti collaterali in grado di confondere persino l’autore.

Il quarto di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:

SQL Server DML Triggers - Tips & Tricks - Part 4 (“Statements that each Trigger should have”)

Ricordate, un Trigger è ottimizzato quando la sua durata è breve!

Il terzo di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:

SQL Server DML Triggers - Tips & Tricks - Part 3 (“Trigger debug”)

Buona lettura!

Il primo di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:

SQL Server DML Triggers - Tips & Tricks - Part 1 (Intro & Triggers activation order)

Buona lettura!

Il secondo di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:

SQL Server DML Triggers - Tips & Tricks - Part 2 (Thought to work on multiple rows)

Buona lettura!

I Trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza un’applicazione standard e chi la produce. Sono spesso i primi imputati quando le performance del database degradano. Sembrano facili da scrivere, ma scrivere Trigger efficienti non è affatto semplice e quando la complessità aumenta, possono presentare effetti collaterali in grado di confondere persino l’autore. Tuttavia, per quanti effetti collaterali possano avere, hanno un pregio dannatamente importante: permettono di risolvere problemi che non potrebbero essere gestiti in qualsiasi altro layer applicativo.

Recentemente ho avuto l’occasione di apprezzare la clausola OUTPUT per determinare il valore degli identificativi univoci (ID) per una colonna con proprietà IDENTITY, per le righe aggiunte a una tabella durante un’operazione di INSERT.

Come indicato sui books online, la clausola OUTPUT, implementata con SQL Server 2005:

“Restituisce le informazioni da (o le espressioni basate su) ogni riga interessata da un’istruzione INSERT, UPDATE, DELETE o MERGE. Questi risultati possono essere restituiti all’applicazione di elaborazione per l’utilizzo nei messaggi di errore, l’archiviazione e altri scopi simili dell’applicazione. I risultati possono anche essere inseriti in una tabella o in una variabile tabella. Inoltre, è possibile acquisire i risultati di una clausola OUTPUT in un’istruzione nidificata INSERT, UPDATE, DELETE o MERGE e inserire tali risultati in una vista o tabella di destinazione”.

Come posso estrarre la lista dei trigger disabilitati per una o più tabelle, o per l’intero database?

Recentemente, ho avuto la necessità di disabilitare temporaneamente (per alcune ore) tutti i trigger definiti su una tabella. La successiva abilitazione, però, doveva tenere conto dei trigger già disabilitati all’origine, che avevo necessità di conoscere prima di eseguire il comando:

ALTER TABLE <nome_tabella> DISABLE TRIGGER ALL;

…in caso contrario, avrei rischiato di abilitare un trigger che in origine era disabilitato!