È consigliabile utilizzare il trigger per aggiornare un'altra tabella?

8

Ho una Objecttabella popolata da un servizio integrato ( che posso modificare se necessario ) da un altro database. In alcuni punti è necessario aggiungere manualmente i post in un'altra tabella, ObjectObjectGroup (ObjectId, ObjectGroupId)necessaria se si Object.ObjectTypedispone di un determinato valore intero. Poiché il servizio di integrazione non gestisce questo tipo di aggiornamento, sto pensando di aggiungere un trigger alla tabella Object che in pseudo-codice sarebbe il seguente:

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

Questa configurazione è saggia o esiste un modo migliore in termini di prestazioni?

sql-server trigger

— Benny Skogberg
fonte

9

Principalmente Copia / Incolla la mia risposta da questa domanda su StackOverflow

I trigger possono essere molto allettanti, quando inizi a usarli per la prima volta sembrano un proiettile magico per tutti i tipi di problemi. Ma fanno accadere cose "magiche", se non si conosce il database completamente, può sembrare che accadano cose davvero strane (come inserimenti in altre tabelle, modifica dei dati di input, ecc.). Prima di implementare le cose come trigger, prenderei seriamente in considerazione invece di imporre l'uso di un'API attorno allo schema (preferibilmente nel database, ma all'esterno se non è possibile).

Alcune cose per le quali userò ancora i trigger

Tenere traccia dei campi "date_created" e "date_last_edited"
Inserimento di "ID" (in Oracle, dove non esiste un campo ID automatico)
Mantenere la cronologia delle modifiche

Cose per le quali non vorresti usare i trigger

regole / logica commerciale
tutto ciò che si collega al di fuori del database (ad es. una chiamata al servizio web)
Controllo di accesso
Tutto ciò che non è transazionale (tutto ciò che fai nel trigger DEVE essere in grado di eseguire il rollback con la transazione)

— Matthew Watson
fonte

4

Sì, è saggio. Questo è lo scopo di un trigger in realtà, per eseguire le azioni necessarie dopo un'operazione di inserimento / aggiornamento / eliminazione su una tabella.

È necessario tenere conto del fatto che un trigger in MS SQL non gestirà ciascuna riga separatamente, ma gestirà contemporaneamente tutte le righe della transazione corrente. Quindi, se un'operazione inserirà 10 righe contemporaneamente, dovrai pensare al codice del tuo trigger per trattare tutte le righe contemporaneamente.

— mariano
fonte

1

Finché il servizio che popola il database non sta facendo tutto ciò di cui l'uomo ha bisogno e fintanto che non può cambiare il servizio (questo è il mio sentimento dopo la descrizione), e la domanda è qui su DBA.SE, non sui programmatori , Dirò che un trigger ben documentato non dovrebbe essere un problema. Ha detto che sta facendo alcune cose manualmente, quindi il cambio di codice non potrebbe essere coinvolto da quello che ho capito ..

— Marian,

1

In questo caso potrebbe essere l'unica opzione praticabile, che non lo rende saggio. La cosa saggia da fare sarebbe di rimandare indietro lo sviluppatore dell'applicazione e farli inserire correttamente in entrambe le tabelle.

— Matthew Watson,

tosse . Vedo dove sta andando. Ci scusiamo per non essere chiaro nella mia domanda sopra. Ho la possibilità di cambiare il servizio di integrazione, anche se non è "di mia proprietà". Da quello che posso leggere è meglio cambiare il servizio di integrazione e usare solo i trigger per i servizi di registrazione / cronologia.

— Benny Skogberg,

3

I trigger sono uno strumento potente e, come qualsiasi altro strumento, devi fare attenzione quando li usi.

Quando commetti un errore in un trigger, le cose possono andare drasticamente in modo sbagliato e, a meno che tu non stia eseguendo delle tracce, non ti accorgerai ...
Esse modificano / inseriscono / eliminano "magicamente" i dati che l'utente del DB (l'applicazione corrente / qualsiasi applicazione futura / uno sviluppatore che esegue un aggiornamento una tantum) non ha realizzato / intende.

Il grosso problema è che dopo aver creato il trigger, non è ovvio per gli altri sviluppatori / utenti che un trigger sia presente e che cosa fa.

Detto questo, sono un ottimo strumento per mantenere l'integrità dei tuoi dati e per il vero controllo delle modifiche.

Devi chiederti se la logica che vuoi inserire nel trigger si adatta meglio alle applicazioni o all'interno del DB, soppesando i rischi su entrambi i lati (cosa succede se arriva una nuova applicazione e non impone questo regola?)

— Andrew Bickerton
fonte