I trigger del database sono malvagi? [chiuso]

I trigger di database sono una cattiva idea?

Nella mia esperienza sono cattivi, perché possono provocare effetti collaterali sorprendenti e sono difficili da eseguire il debug (specialmente quando un grilletto spara un altro). Spesso gli sviluppatori non pensano nemmeno di vedere se c'è un trigger.

D'altra parte, sembra che se si ha la logica che deve verificarsi negli straordinari, una nuova FOOviene creata nel database, quindi il posto più sicuro per metterlo è un trigger di inserimento sulla tabella FOO.

L'unica volta che utilizziamo i trigger è per cose davvero semplici come l'impostazione di ModifiedDate.

I principali problemi con i trigger sono

• Sono completamente globali - si applicano indipendentemente dal contesto dell'attività della tabella;
• Sono furtivi; è facile dimenticare che sono lì fino a quando non ti fanno del male con conseguenze indesiderate (e molto misteriose).

Questo significa solo che devono essere usati con attenzione per le circostanze appropriate; che nella mia esperienza è limitato a problemi di integrità relazionale (a volte con granularità più fine di quanto si possa ottenere in modo dichiarativo); e di solito non per scopi commerciali o transazionali. YMMV.

No, in realtà sono una buona idea. Se c'è un problema con i tuoi trigger specifici, allora non li stai facendo bene, ma di solito significa che c'è un problema con la tua implementazione, non il concetto di trigger stessi :-).

Utilizziamo i trigger molto perché pone l'attività specifica del DBMS sotto il controllo del database a cui appartiene. Gli utenti di un DBMS non dovrebbero preoccuparsi di questo tipo di cose. L'integrità dei dati risiede nel database stesso, non nelle applicazioni o negli utenti che lo utilizzano. Senza vincoli, trigger e altre funzionalità nel database, è lasciato alle applicazioni per applicare le regole e per distruggere i dati è sufficiente una sola applicazione / utente non valida o errata.

Ad esempio, senza trigger, cose meravigliose come le colonne generate automaticamente non esisterebbero e dovresti elaborare una funzione su ogni riga quando le selezioni. È probabile che uccida le prestazioni del DBMS, molto meglio creare la colonna generata automaticamente al momento dell'inserimento / aggiornamento poiché è l'unica volta che cambia.

Inoltre, la mancanza di trigger impedirebbe l'applicazione di regole di dati nel DBMS come i pre-trigger per garantire che le colonne abbiano un formato specifico. Si noti che questo è diverso dalle regole di integrità dei dati che sono generalmente solo ricerche di chiavi esterne.

Gli strumenti non sono mai cattivi. Le applicazioni di questi strumenti possono essere malvagie.

Sono d'accordo. I problemi con i trigger sono le persone, non i trigger. Anche se è più da guardare, più da considerare e aumenta l'onere dei programmatori che controllano le cose correttamente, non scartiamo gli indici per semplificarci la vita. (Gli indici errati possono essere negativi tanto quanto i trigger negativi)

L'importanza dei trigger (nella mia mente) è che ...
- Qualsiasi sistema dovrebbe essere sempre in uno stato valido
- Il codice per applicare questo stato valido deve essere centralizzato (non scritto in ogni SP)

Dal punto di vista della manutenzione, un trigger è molto utile per programmatori concorrenti e problemi per quelli più giovani / dilettanti. Tuttavia, queste persone hanno bisogno di imparare e crescere in qualche modo.

Immagino che dipenda dal tuo ambiente di lavoro. Hai persone affidabili che imparano bene e ci si può fidare di essere metodiche? Altrimenti apparentemente hai due scelte:
- Accetta che dovrai perdere funzionalità per compensare
- Accetta che hai bisogno di persone diverse o di una migliore formazione e gestione

Sembrano aspri, e immagino che lo siano. Ma è la verità di base, nella mia mente ...

Penso che i trigger non siano non solo malvagi, ma necessari per una buona progettazione del database. I programmatori di applicazioni pensano che i database siano interessati solo dalla loro applicazione. Spesso hanno torto. Se l'integrità dei dati deve essere mantenuta indipendentemente da dove provenga la modifica dei dati, i trigger sono un requisito ed è sciocco evitarli perché alcuni programmatori sono troppo etnocentrici per considerare che qualcosa di diverso dalla loro preziosa applicazione potrebbe influenzare le cose. Non è difficile progettare, testare o risolvere un problema se si è sviluppatori di database competenti. Né è difficile determinare che un innesco sta causando un risultato inaspettato se ti viene in mente (come fa a me) di guardare lì. Se compare un errore che dice che una tabella a cui non sto facendo riferimento nel mio SP ha un errore FK, So senza nemmeno pensarci che il trigger sta causando il problema e quindi dovrebbe qualsiasi sviluppatore di database competente. Mettere le regole di business solo nell'applicazione è la causa numero uno che ho trovato di dati errati in quanto altri non hanno idea che la regola esista e violi nei loro processi. Le regole incentrate sui dati appartengono al database e i trigger sono fondamentali per applicare quelle più complesse.

Principalmente sì.

La difficoltà con un grilletto è che fa cose "dietro la schiena"; lo sviluppatore che mantiene l'applicazione potrebbe facilmente non rendersi conto che è lì e apportare modifiche che rovinano le cose senza nemmeno accorgersene.

Crea uno strato di complessità che aggiunge solo lavori di manutenzione.

Piuttosto che usare un trigger, una procedura / routine memorizzata, in genere può essere fatta per fare la stessa cosa, ma in modo chiaro e mantenibile: chiamare una routine memorizzata significa che lo sviluppatore può guardare il suo codice sorgente e vedere esattamente cosa sta succedendo.

I trigger sono estremamente potenti e utili, ci sono molti scenari in cui un trigger è la migliore soluzione a un problema.

Sono anche un ottimo strumento di "hacking". Ci sono spesso situazioni in cui non si ha il controllo immediato sia del codice che del database. Se devi attendere 2 mesi per la prossima versione principale del tuo codice, ma puoi applicare immediatamente una patch al tuo database, allora puoi mettere un trigger su una tabella per eseguire alcune funzionalità aggiuntive. Quindi, quando è possibile il rilascio del codice, è possibile sostituire questo trigger con la versione codificata della stessa funzionalità, se lo si desidera.

Alla fine della giornata, tutto è "malvagio" se non sai cosa sta facendo. Decidere che i grilletti sono perché ci sono sviluppatori che non li capiscono è come sostenere che le auto sono cattive perché alcune persone non possono guidare ...

I trigger hanno i loro usi: la registrazione / il controllo e il mantenimento di una data "ultima modifica" sono due usi molto validi che sono stati menzionati nelle risposte precedenti.

Tuttavia, uno dei principi fondamentali del buon design è che le regole di business / la logica di business / qualunque cosa tu voglia chiamarla dovrebbe essere concentrata in un unico posto. Inserire parte della logica nel database (tramite trigger o processi memorizzati) e alcuni nell'applicazione viola tale principio. Duplicare la logica in entrambi i posti è ancora peggio, poiché invariabilmente si sincronizzeranno tra loro.

C'è anche il problema del "principio della minima sorpresa" che è già stato menzionato.

I trigger sono un buon strumento se usati correttamente. Soprattutto per cose come il controllo delle modifiche, il popolamento di tabelle di riepilogo, ecc.

Ora possono essere "cattivi" se finisci in "inferno di innesco" con un innesco che dà il via ad altri innescatori. Una volta ho lavorato su un prodotto COTS in cui avevano quelli che chiamavano "grilletti flessibili". Questi trigger sono stati memorizzati in una tabella man mano che le punture sql dinamiche venivano compilate ogni volta che venivano eseguite. I trigger compilati farebbero una ricerca e vedrebbero se quella tabella aveva dei trigger flex da eseguire, quindi compilare ed eseguire il trigger "flex". In teoria sembrava un'idea davvero interessante perché il prodotto era facilmente personalizzabile ma la realtà era che il database era praticamente esploso a causa di tutte le compilazioni che doveva fare ...

Quindi sì, sono fantastici se mantieni ciò che stai facendo in prospettiva. Se è qualcosa di piuttosto semplice come auditing, riepilogo, auto-sequencing, ecc., Nessun problema. Basta tenere presente il tasso di crescita della tabella e l'impatto del trigger sulle prestazioni.

Ad alto livello ci sono due casi d'uso per i trigger1

1) Far accadere cose "automagicamente". In questo caso, i trigger causano un effetto collaterale, cambiano i dati in modi che non erano previsti a causa dell'inserimento, dell'aggiornamento o dell'eliminazione (primitivi) dell'operatore che è stato eseguito e ha provocato l'attivazione del trigger.

Il consenso generale qui è che i trigger sono davvero dannosi. Perché cambiano la semantica ben nota di un'istruzione INSERT, UPDATE o DELETE. La modifica della semantica di questi tre operatori SQL primitivi morderà altri sviluppatori che in futuro dovranno lavorare sulle tabelle del database che non si comportano più nei modi previsti quando vengono utilizzati su di essi con le primitive SQL.

2) Per applicare regole di integrità dei dati, diverse da quelle che possiamo trattare in modo dichiarativo (usando CHECK, PRIMARY KEY, UNIQUE KEY e FOREIGN KEY). In questo caso d'uso, tutti i trigger sono dati QUERY (SELECT) per verificare se la modifica apportata da INSERT / UPDATE / DELETE è consentita o meno. Proprio come i vincoli dichiarativi fanno per noi. Solo in questo caso (gli sviluppatori) abbiamo programmato l'applicazione.

L'uso di trigger per quest'ultimo caso d'uso non è dannoso.

Sto scrivendo un blog su questo: http://harmfultriggers.blogspot.com

So che gli sviluppatori che pensano che i trigger debbano essere sempre utilizzati laddove è il modo più diretto per ottenere le funzionalità che desiderano e gli sviluppatori che non lo faranno mai. È quasi come un dogma tra i due campi.

Tuttavia, personalmente sono completamente d'accordo con MarkR: puoi (quasi) scrivere sempre un codice funzionalmente equivalente al trigger che sarà più evidente e quindi più facile da mantenere.

Non male. In realtà semplificano cose come

1. Registrazione / controllo delle modifiche ai record o persino degli schemi di database

Potresti avere un trigger su ALTER TABLE che ripristina le modifiche nel tuo ambiente di produzione. Ciò dovrebbe impedire qualsiasi modifica accidentale della tabella.

2. Applicazione dell'ingerenza referenziale (relazioni chiave primaria / esterna, ecc.) Su più database

No, non sono cattivi - sono solo fraintesi MrGreen

I trigger hanno un uso valido, ma troppo spesso come un hack retrò che alla fine peggiora le cose.

Se stai sviluppando un DB come parte di un'applicazione, la logica dovrebbe essere sempre nel codice o negli sprocs che effettuano la chiamata. I trigger porteranno solo a debug-dolore in seguito.

Se capisci come il blocco, il deadlock e come i DB accedono ai file su disco, allora usare i trigger nel modo giusto (ad esempio controllo o archiviazione dell'accesso diretto al DB) può essere davvero prezioso.

Dire che sono cattivi è un'esagerazione ma possono causare delle maglie. Quando l'attivazione di un grilletto provoca altri grilletti, diventa davvero complicato. Diciamo che sono fastidiosi: http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

Fare la logica di business in Oracle con i trigger è più difficile di quanto sembri a causa di problemi con più concorrenza. Non vedi le modifiche in un'altra sessione fino a quando non viene eseguito il commit delle altre sessioni.

Non sono sicuramente cattivi. Ho trovato i trigger preziosi durante il refactoring degli schemi di database, durante la ridenominazione di una colonna o la divisione di una colonna in due colonne o viceversa (esempio: caso nome / cognome) e assistenza alla transizione.

Sono anche molto utili per l'auditing.

Questa risposta si applica specificamente a SQL Server. (sebbene possa applicarsi anche ad altri RDBMS, non ne ho idea. Avrei preferito dargli una risposta qui, ma questo è stato chiuso come un inganno.)

Un aspetto non menzionato finora in nessuna delle risposte è la sicurezza. Poiché, per impostazione predefinita, i trigger vengono eseguiti nel contesto dell'utente che esegue l'istruzione che provoca l'attivazione del trigger, ciò può causare una minaccia alla sicurezza a meno che tutti i trigger non vengano esaminati.

L'esempio fornito in BOL sotto l' intestazione " Gestione della sicurezza dei trigger " è di un utente che crea un trigger contenente il codice GRANT CONTROL SERVER TO JohnDoe ;per aumentare le proprie autorizzazioni.

Se ci sono effetti collaterali, è un problema in base alla progettazione. In alcuni sistemi di database, non esiste altra possibilità per impostare un campo di incremento automatico, ad es. Per un campo ID chiave primaria.

Penso che possano essere malvagi, ma solo cattivi come qualsiasi altra cosa in fase di sviluppo.

Anche se non ho molta esperienza con loro, li ho avuti su un recente progetto a cui ho lavorato che mi ha portato a questa conclusione. Il problema che ho con loro è che possono causare la logica di business in due posizioni, una libreria di codici e un database.

Lo vedo come un argomento simile con l'utilizzo di sprocs. Avrai spesso sviluppatori che sono davvero bravi a scrivere la logica di business nel database nel database, mentre le persone che non lo sono avranno la loro logica di business altrove.

Quindi la mia regola empirica è guardare qual è la struttura del tuo progetto. Se sembra fattibile avere una logica di business memorizzata nel database, potrebbe essere utile disporre di trigger.

In effetti, abbastanza spesso i trigger vengono utilizzati in modo improprio. In realtà nella maggior parte dei casi non ne hai nemmeno bisogno. Ma ciò non li rende necessariamente cattivi.

Uno scenario che mi viene in mente in cui i trigger sono utili è quando hai un'applicazione legacy per la quale non hai il codice sorgente e non c'è modo di cambiarlo.

L'idea di trigger non è malvagia, limitare la nidificazione di trigger è malvagia.