Trigger SQL e quando o quando non usarli.

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

La seguente discussione è basata 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 codice procedurale esplicito con ogni comando CRUD su ogni tabella.

I trigger ti danno il controllo appena prima che i dati vengano modificati e subito dopo la modifica dei dati. Questo consente:

• Controllo come accennato prima
• Convalida e controllo della sicurezza aziendale se lo si desidera. A causa di questo tipo di controllo, è possibile eseguire attività come la formattazione delle colonne prima e dopo l'inserimento nel database.

I was always told, only use triggers if you really need to and opt to use stored procedures instead if possible.

Forse alcuni dei motivi sono:

1. Alcune funzioni attivate dai trigger ai vecchi tempi potevano ora essere eseguite in altri modi, ad esempio 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. Vedete il loro effetto quando vedete i cambiamenti dei dati ed è talvolta sconcertante capire perché il cambiamento si è verificato a meno che non si sappia che c'è un innesco o più recitazione sul tavolo (s).
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. Di nuovo, avrai bisogno di una buona documentazione per questo.

Alcune differenze tra i trigger e le stored procedure non trigger sono (tra gli altri):

• Una procedura memorizzata non trigger è come un programma che deve essere invocato esplicitamente dal codice o da uno scheduler o da un lavoro batch, ecc. per fare il suo lavoro, mentre un trigger è un tipo speciale di stored procedure che spara come risposta di un evento piuttosto che essere eseguito direttamente dall'utente. L'evento potrebbe essere un cambiamento di dati in una colonna di dati, ad esempio.
• I trigger hanno tipi. Trigger DDL e trigger DML (di tipi: INSTEAD OF, FOR, e AFTER)
• Le stored procedure non trigger possono fare riferimento a qualsiasi tipo di oggetto, tuttavia, per fare riferimento a una vista, è necessario utilizzare i trigger INSTEAD OF.
• In SQLServer, puoi avere qualsiasi numero su stored procedure non trigger ma solo 1 trigger di INSTEAD per tabella.

I trigger sono un requisito per qualsiasi complessa regola di integrità dei dati. Questi non possono essere applicati ovunque tranne il database o si avranno problemi di integrità dei dati.

Sono anche il posto migliore per il controllo a meno che non vogliate catturare tutte le modifiche al database (che è il problema dell'auditing dall'applicazione).

I trigger possono causare problemi di prestazioni se non scritti attentamente e non abbastanza sviluppatori sono abbastanza informati per scriverli bene. Questo fa parte di dove ottengono il loro cattivo rap.

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

È facile scrivere trigger non validi che fanno cose stupide come provare a inviare email. Vuoi davvero non essere in grado di modificare i record nel db se il server di posta elettronica si arresta?

Nel server SQL, i trigger operano su un batch di record. Troppo spesso gli sviluppatori pensano di dover gestire solo inserimenti, aggiornamenti o eliminazioni di record. 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 di molte modifiche ai record. Dimenticare di fare il secondo test può portare a trigger estremamente scarsi o alla perdita di integrità dei dati.

Un altro caso di utilizzo che ho incontrato personalmente è per i database a cui si accede da più di un programma. Se vuoi implementare funzionalità ma non riprogettare tutti i sistemi, un trigger crea una soluzione sensata.

Ad esempio, di recente ho lavorato a un database che esisteva in precedenza solo come sistema di un ufficio. Quando una webapp è stata scritta per interfacciarla, volevamo implementare un sistema di notifica (simile a stackexchange, ad esempio), che sarebbe stato generato 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 attivassero un trigger per creare la notifica per il frontend e comunicare all'utente che la transazione era stata elaborata dall'ufficio.

Uso dei trigger del database

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

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

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

Invece accumuli modifiche in una coda. Alcuni programmi esterni invieranno periodicamente piccoli batch di dati in coda.

Il sistema ha oltre 2000 stored procedure. 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 puoi mettere un trigger sul tavolo per mantenere aggiornata la coda. Garantito di non perdere nulla. Una posizione centrale Penalità per le prestazioni? Non proprio perché l'impatto del popolamento della coda non può essere evitato se è per trigger o esterno.

In questo scenario direi che non usare un trigger è una cattiva scelta progettuale. Se in seguito si desidera utilizzare un nuovo metodo per spingere i dati (ad esempio la coda non sta funzionando) e l'interfaccia cambia, si viene protetti se si utilizza il trigger. I trigger sono spesso la scelta migliore. Non ascoltare fanatici anti-trigger dogmatici.

Un trigger che invia email non è necessariamente un'idea "stupida". Quello che è stupido non è prevedere l'interruzione della posta elettronica nella progettazione e gestirla con garbo senza perdita di dati. La parte "stupida" di questo è davvero pessima per la gestione inesistente degli errori da parte di sviluppatori pigri che si sentono immuni da errori.

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

Il bigottismo è davvero paralizzante.