PRIMA o DOPO l'attivazione per mantenere il registro di controllo

Question

Ho letto il flusso di commenti di MySql 5.0 su crea una pagina trigger  e vorrei chiedere alla community se le raccomandazioni sono buone & amp; se si applicano ancora a 5.1. Quello che ho notato giocando con i trigger oggi è che è impossibile aggiornare un campo nella vecchia tabella usando un AFTER UPDATE.

1. Prestare attenzione con i trigger PRIMA. Potrebbero verificarsi vincoli, in particolare se si utilizza il motore InnoDB, in cui l'inserimento non riuscirà, ma le azioni del trigger PRIMA avranno esito positivo.
2. Utilizzare PRIMA i trigger principalmente per vincoli o regole, non per transazioni, modificando le colonne NEW. * dovrebbe andare bene.
3. Attiva i trigger AFTER per la maggior parte delle altre operazioni, come l'inserimento in una tabella cronologica o l'aggiornamento di una denormalizzazione.

Answer 1

Sì. AFAIK, MySQL 5.1 non ha apportato modifiche alla semantica del funzionamento dei trigger. MySQL tenta di supportare la specifica ANSI / ISO SQL per la semantica del trigger.

Puoi immaginare che una sequenza di operazioni venga eseguita mentre una riga viene scritta nel database:

1. Esegui PRIMA dei trigger
2. Valuta i vincoli, applica NOT NULL , applica i valori DEFAULT
3. Scrivi la riga nel database
4. Aggiorna indici
5. Esegui AFTER trigger

Una volta raggiunto il trigger AFTER, è troppo tardi per modificare i valori nella riga. In alcuni database, è possibile impostare NEW.somecolumn = 1234 ma questa modifica viene silenziosamente ignorata al termine del trigger AFTER. In altri database, ti aiuta a capire il tuo errore dandoti un errore quando definisci il trigger o quando esegui il trigger.

I trigger AFTER vengono utilizzati al meglio per azioni aggiuntive da eseguire a seguito di INSERT / UPDATE della riga, ad esempio la registrazione di controllo menzionata. Per prima cosa, MySQL consente solo un trigger per azione per tabella, quindi se si utilizza anche un trigger PRIMA per modificare i valori e applicare le regole di business, ora è possibile almeno conservare le azioni extra in un trigger separato. Ciò semplifica l'aggiornamento dell'uno o dell'altro.

L'altra considerazione è che probabilmente dovresti fare ulteriori azioni solo dopo sai che la riga è stata salvata correttamente. Per esempio. non sarebbe corretto registrare una modifica in un trigger PRIMA e quindi interrompere la modifica a causa di un vincolo NOT NULL.

Per le azioni DELETE in cui è necessario rimuovere le righe dipendenti in altre tabelle, potrebbe essere necessario farlo in un trigger PRIMA.