Trigger SQL e quando o quando non utilizzarli.

Quando stavo inizialmente imparando a conoscere SQL, mi veniva sempre detto, utilizzare i trigger solo se proprio necessario e optare invece per utilizzare le stored procedure, se possibile.

Ora purtroppo a quel tempo (alcuni anni fa) non ero così curioso e attento ai fondamenti come lo sono ora, quindi non ho mai chiesto il motivo.

Qual è l'opinione della comunità in questo? È solo la preferenza personale di qualcuno, o dovrebbero essere evitati i trigger (proprio come i cursori) a meno che non ci sia una buona ragione per loro.

L' articolo di Wikipedia sui trigger di database presenta una buona panoramica di cosa sono i trigger e quando utilizzarli in database diversi.

La seguente discussione si basa solo su SQL Server.

L'uso dei trigger è abbastanza valido quando il loro uso è giustificato. Ad esempio, hanno un buon valore nel controllo (mantenendo la cronologia dei dati) senza richiedere un codice procedurale esplicito con ogni comando CRUD su ogni tabella.

I trigger ti danno il controllo subito prima della modifica dei dati e subito dopo la modifica dei dati. Ciò consente di:

• Auditing come menzionato prima
• Convalida e controllo della sicurezza aziendale se è desiderato. A causa di questo tipo di controllo, è possibile eseguire attività come la formattazione delle colonne prima e dopo gli inserimenti nel database.

Mi è sempre stato detto, utilizzare i trigger solo se è necessario e optare invece per l'utilizzo di stored procedure, se possibile.

Forse alcuni dei motivi sono:

1. Alcune funzioni che i trigger erano soliti svolgere in passato potevano ora essere eseguite in altri modi come l'aggiornamento dei totali e il calcolo automatico su una colonna.
2. Non vedi dove viene invocato il trigger esaminando il codice da solo senza sapere che esistono. Vedi il loro effetto quando vedi i cambiamenti dei dati e a volte è sconcertante capire perché il cambiamento è avvenuto a meno che tu non sappia che c'è un trigger o che agisce di più sui tavoli.
3. Se si utilizzano diversi controlli del database come CHECK, RI, Trigger su più tabelle, il flusso dettagliato della transazione diventa complesso da comprendere e mantenere. Dovrai sapere esattamente cosa succede quando. Ancora una volta, avrai bisogno di una buona documentazione per questo.

Alcune differenze tra trigger e procedure memorizzate non trigger sono (tra le altre):

• Una procedura memorizzata senza trigger è come un programma che deve essere richiamato esplicitamente dal codice o da uno scheduler o da un processo batch, ecc. Per fare il suo lavoro, mentre un trigger è un tipo speciale di procedura memorizzata che viene attivata come risposta di un evento piuttosto che essere eseguita direttamente dall'utente. Ad esempio, l'evento potrebbe essere una modifica dei dati in una colonna di dati.
• I trigger hanno tipi. Trigger DDL e trigger DML (di tipi: INSTEAD OF, For e AFTER)
• Le procedure memorizzate senza trigger possono fare riferimento a qualsiasi tipo di oggetto, tuttavia, per fare riferimento a una vista, è necessario utilizzare i trigger INSTEAD OF.
• In SQLServer, è possibile avere un numero qualsiasi su stored procedure senza trigger ma solo 1 trigger INSTEAD OF per tabella.

I trigger sono un requisito per eventuali regole complesse di integrità dei dati. Questi non possono essere applicati ovunque tranne che nel database o si avranno problemi di integrità dei dati.

Sono anche il posto migliore per il controllo a meno che non si desideri acquisire tutte le modifiche al database (che è il problema del controllo dall'applicazione).

I trigger possono causare problemi di prestazioni se non scritti con cura e non abbastanza sviluppatori sono abbastanza informati per scriverli bene. Questo è parte di dove ottengono il loro brutto rap.

I trigger sono spesso più lenti di altri mezzi per mantenere l'integrità dei dati, quindi se è possibile utilizzare un vincolo di controllo, utilizzare quello invece di un trigger.

È facile scrivere cattivi trigger che fanno cose stupide come provare a inviare e-mail. Vuoi davvero non essere in grado di cambiare i record nel db se il server di posta elettronica non funziona?

Nel server SQL, i trigger operano su un batch di record. Troppo spesso gli sviluppatori pensano di dover gestire solo un record di inserimenti, aggiornamenti o eliminazioni. Questo non è l'unico tipo di modifica dei dati che si verifica in un database e tutti i trigger devono essere testati nelle condizioni di 1 modifica del record e molte modifiche del record. Dimenticare di eseguire il secondo test può causare trigger con prestazioni estremamente scarse o una perdita di integrità dei dati.

Utilizzo dei trigger del database

1. Per guidare automaticamente i valori di colonna.
2. Per applicare vincoli di integrità complessi.
3. Per applicare regole aziendali complesse.
4. Per personalizzare autorizzazioni di sicurezza complesse.
5. Per mantenere le tabelle replicate.
6. Per controllare la modifica dei dati.

Un altro caso d'uso che ho riscontrato personalmente è per i database a cui accedono più di un programma. Se vuoi implementare la funzionalità ma non riprogettare tutti i sistemi per essa, un trigger è una soluzione sensata.

Ad esempio, di recente ho lavorato su un database che in precedenza era esistito esclusivamente come un sistema per ufficio. Quando una webapp è stata scritta per interfacciarsi con essa, volevamo implementare un sistema di notifica (simile allo stackexchange, ad esempio), che sarebbe stato attivato da più eventi, come l'elaborazione di una transazione, e così via. Siamo stati in grado di implementare un trigger in modo che gli aggiornamenti nel backend dell'ufficio abbiano attivato un trigger per creare la notifica per il frontend e dire all'utente che la loro transazione era stata elaborata dall'ufficio.

I trigger possono essere utilizzati per imporre vincoli al database che non possono essere applicati durante la creazione dello schema del database e qualsiasi istruzione DML.

Diciamo che devi trasferire i dati a un sistema di terze parti in tempo quasi reale. La tabella contiene 950 gigabyte di dati, quindi è troppo grande per inviare semplicemente l'intera tabella all'app di terze parti.

Invece si accumulano le modifiche in una coda. Alcuni programmi esterni invieranno periodicamente piccoli lotti di dati in coda.

Il sistema ha oltre 2000 procedure memorizzate. Sai anche che tonnellate di sql esistono nel codice sorgente. Per garantire che la coda sia popolata correttamente, dovrai cercare tra tutti i proc e il codice memorizzati e sperare di non perdere nulla.

Invece è possibile inserire un trigger sulla tabella per mantenere la coda aggiornata. Garantito da non perdere nulla. Una posizione centrale. Pena di prestazione? Non proprio perché il colpo di popolamento della coda non può essere evitato sia per innesco che per esterno.

In questo scenario direi che non usare un trigger è una cattiva scelta progettuale. Se in seguito desideri utilizzare un nuovo metodo di invio dei dati (supponi che la coda non funzioni) e l'interfaccia cambi, sei protetto se usi il trigger. I trigger sono spesso la scelta migliore. Non ascoltare i fan dogmatici anti-trigger.

Un trigger che invia e-mail non è necessariamente un'idea "stupida". Ciò che è stupido non è anticipare l'interruzione della posta elettronica nella progettazione e gestirla con grazia senza perdita di dati. La parte "stupida" di questo è davvero negativa per la gestione degli errori inesistenti da parte di sviluppatori pigri che si sentono immuni dal commettere errori.

Vorrei anche offrire l'osservazione che un trigger può essere mantenuto semplice invocando una stored procedure / funzione che può essere arbitrariamente complicata e può essere riutilizzabile da trigger multipli o altre stored procedure. Ecco perché ci sono pacchetti e librerie.

Il bigottismo è davvero paralizzante.