Pro e contro di trigger vs stored procedure per Denormalizzazione

Question

Quando si tratta di denormalizing dati in un database transazionale per le prestazioni, ci sono (almeno) tre differenti approcci:

1. aggiornamenti far passare le stored procedure che aggiornare sia i dati transazionali normalizzati sia i dati denializzati di reporting/analisi;

2. Attiva i trigger nelle tabelle transazionali che aggiornano le tabelle secondarie; questo è quasi sempre il percorso intrapreso nel mantenere le storie;

3. Rinviare l'elaborazione a un processo batch notturno, possibilmente facendo un ETL in un data mart/warehouse.

Supponiamo ai fini di questa domanda che l'opzione # 3 non è praticabile, perché il dominio richiede i dati denormalizzati essere coerenti con i dati normalizzati in ogni momento. Gli aggregati gerarchici, di cui mi occupo piuttosto frequentemente, ne sono un esempio.

Ho usato entrambi i primi due approcci un bel po 'e ultimamente mi sono orientato verso l'approccio basato sul trigger, ma mi chiedo se ci sono "trucchi" che non ho ancora scoperto e ho pensato che valesse la pena di porre questa domanda, quindi avrò alcune idee da tenere a mente quando prendo decisioni a lungo termine in futuro.

Quindi, secondo la vostra esperienza, quali sono i pro e i contro di entrambi gli strumenti allo scopo specifico di mantenere i dati denormalizzati in tempo reale? In quali situazioni sceglieresti l'una sull'altra e perché?

(PS Si prega di non risposte come "trigger sono troppo complicate" o "tutti gli aggiornamenti devono sempre passare attraverso una stored procedure" - rendono opportuno il contesto della questione.)

Answer 1

trigger sono utili dove multipla aggiornare i percorsi su una tabella.

Usiamo stored procedure e hanno circa 4 percorsi almeno (Aggiungere, Update, Disattiva, Copy)

E 'più facile lavorare con i dati che abbiamo appena inserito/aggiornata in un trigger, non importa quale azione che fare o quante righe influenziamo.

Un proc memorizzato lavora per un unico percorso di aggiornamento solo mi sento: a meno che non si vuole ripetere il codice ...

Ora, try/catch in trigger significa corretta gestione degli errori prevedibili,: trigger su SQL Server 2000 e in precedenza ha causato l'interruzione di batch su errore/rollback che non è l'ideale (per non dire altro!). Quindi, i trigger sono ora più affidabili in ogni caso.

Answer 2

I trigger sono effetti secondari automatici e quasi sicuramente ti morderanno lungo la linea quando vuoi fare qualcosa e non puoi a causa degli effetti collaterali dei trigger. Principalmente cose come avere il tuo sistema partecipare ad alcune Transazioni XA con altri sistemi esterni. I trigger rendono questo IMPOSSIBILE. Inoltre, la logica Side Effect può essere attivata SOLO attivando nuovamente l'attivatore Trigger. Se vuoi ricreare i dati nel magazzino non puoi semplicemente eseguire alcune procedure e ricrearle, devi eseguire tutte le attività che generano i trigger, questo è un incubo. INSERTI, AGGIORNAMENTI e DELETE dovrebbero essere idempotenti e ortogonali. Trigger complicano inutilmente i flussi di lavoro, anche se pensi che li stiano semplificando, non lo sono.

Answer 3

Dipende dai requisiti aziendali e dal modo in cui viene utilizzato il database. Ad esempio, supponiamo che ci siano molte applicazioni e molte importazioni che influiscono sulla tabella (abbiamo centinaia di cose che possono influenzare le nostre tabelle). Supponiamo anche che occasionalmente sia necessario scrivere query eseguite da SSMS (sì anche su prod) per fare cose come aggiornare tutti i prezzi del 10%. Se fai questo tipo di cose allora un proc memorizzato non è pratico, non avrai mai tutti i modi possibili per influenzare il database coperto.

Se questa modifica dei dati è necessaria per l'integrità dei dati o molte applicazioni o processi (importazioni, processi di SQL Server, ecc.) Possono influenzare i dati, quindi appartiene al trigger.

Se la modifica dei dati è necessaria solo a volte o si ha il controllo totale di come i dati vengono modificati da una sola applicazione, quindi un proc memorizzato va bene.