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)
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)
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:
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:
