Un grande database transazionale SQL ha più di 100 tabelle (e crescerà). Uno di questi è chiamato Ordina . Quindi, esiste un'altra tabella WorkLoad che deriva dall'ordine e da molte altre tabelle unite che contengono un elenco di tutti gli ordini attivi. Ogni volta che viene creato un record di ordine, se soddisfa determinate condizioni, dovrebbe essere immediatamente inserito nella tabella WorkLoad. E infine, c'è una terza tabella WorkLoadAggregation che mostra i dati aggregati raggruppati per data e negozio ed è completamente costruita dalla tabella WorkLoad. WorkLoadAggregation dovrebbe inoltre visualizzare dati in tempo reale, il che significa che se un record viene inserito nella tabella WorkLoad, è necessario aggiornare anche l'aggregazione di data / negozio.
La mia idea era di gestire questo per trigger:
- Quando il record è inserito nella tabella degli ordini , avvia la procedura memorizzata delle chiamate che inserisce i record nella tabella WorkLoad
- Quando il trigger Il record dell'ordine viene eliminato cancella il record dalla tabella WorkLoad
- Quando Il record dell'ordine viene aggiornato in modo che non soddisfi le condizioni WorkLoad, il trigger cancella il record dalla tabella WorkLoad
- Quando il record è inserito / eliminato / aggiornato nella tabella WorkLoad , avvia la procedura memorizzata chiamate che aggiorna il record aggregato di data / negozio nella tabella WorkLoadAggregation
Non ho usato trigger tanto in dbs di transazioni così grandi e per chiamate così frequenti. C'è qualcosa di male in questo approccio? La mia più grande preoccupazione è l'uso di "trigger concatenati", il che significa che il trigger su una tabella attiva il trigger su un'altra tabella. Ho letto alcuni articoli che affermano che gli sviluppatori dovrebbero essere molto cauti quando usano i grilletti. Ci sono soluzioni migliori? Dovrei prendere in considerazione una soluzione NoSQL?