I trigger diminuiscono le prestazioni? Tabelle inserite e cancellate?

Question

Supponiamo di avere stored procedure che eseguono operazioni di inserimento/aggiornamento/cancellazione sulla tabella.

In base a determinati criteri, desidero eseguire alcune operazioni.

Devo creare il trigger o eseguire l'operazione nella stored procedure stessa.

L'utilizzo dei trigger diminuisce le prestazioni?

fa queste due tabelle viz Inserito e cancellati esiste (persistente) o sono creati in modo dinamico?

Se vengono creati dinamicamente, presenta problemi di prestazioni.

Se sono tabelle persistenti, allora dove sono?

anche se exixts poi Posso accedere Inserita e omessa tabelle nelle stored procedure?

Answer 1

Prestazioni su cosa? il trigger eseguirà un aggiornamento sul DB dopo l'evento in modo che l'utente del sistema non sappia nemmeno che sta succedendo. Accade sullo sfondo.

La tua domanda è formulata in un modo abbastanza difficile da comprendere.

Answer 2

Sì, una tabella con un trigger non funzionerà come sarebbe senza di esso. La logica dice che fare qualcosa è più costoso che non fare nulla.

Penso che la tua domanda sarebbe più significativa se chiedessi se è più performante di qualche altro approccio che non hai specificato.

In definitiva, selezionerei lo strumento più appropriato per il lavoro e mi preoccupo solo delle prestazioni se c'è un problema, non prima ancora di aver implementato una soluzione.

Le tabelle inserite e cancellate sono disponibili all'interno del trigger, quindi chiamarle da stored procedure è un no-go.

Answer 3

Riduce le prestazioni della query per definizione: la query sta quindi facendo qualcosa che altrimenti non avrebbe fatto.

L'altro modo di guardarlo è questo: se dovessi fare manualmente qualunque cosa il trigger stia facendo comunque aumentano le prestazioni salvando un round trip.

Fai un ulteriore passo avanti: questo vantaggio scompare se utilizzi una procedura memorizzata e stai eseguendo comunque un viaggio andata e ritorno su un server.

Quindi dipende da come lo si guarda.

Answer 4

Sarà meno performante di fare la stessa cosa in un proc memorizzato. Probabilmente no, ma con tutte le domande sulle prestazioni l'unico modo per sapere veramente è testare entrambi gli approcci con un set di dati realistico (se hai una tabella di record da 2.000.000 non testare con una tabella con 100 record!

Detto questo, la scelta tra un trigger e un altro metodo dipende interamente dalla necessità che l'azione in questione avvenga indipendentemente dal modo in cui i dati vengono aggiornati, eliminati o inseriti. Se questa è una regola aziendale che deve sempre accadere indipendentemente da cosa, un trigger è il posto migliore per esso o alla fine si avranno problemi di integrità dei dati. I dati nei database sono spesso modificati da fonti diverse dalla GUI.

Quando si scrive un trigger, tuttavia, è necessario tenere presente diverse informazioni. Innanzitutto, il trigger si attiva una volta per ogni batch, quindi, indipendentemente dall'inserimento di un record o di 100.000 record, il trigger viene attivato solo una volta. Non puoi mai presumere che solo un record sarà influenzato. Né puoi supporre che sarà sempre solo un piccolo set di record. Questo è il motivo per cui è fondamentale scrivere tutti i trigger come se si sta per inserire, aggiornare o eliminare un milione di righe. Ciò significa che la logica basata su set e senza cursori o cicli while se possibile. Non prendere un proc memorizzato scritto per gestire un record e chiamarlo in un cursore in un trigger.

Inoltre, non inviare e-mail da un cursore, non si desidera interrompere tutti gli inserimenti, gli aggiornamenti o le eliminazioni se il server di posta elettronica non è attivo.