Originariamente inviato da archivio
...Ma, se potresti postare un piccolo esempio te ne sarei grado, poi penso che ricercando...
Bhè è più semplice di quello che sembra.
La cosa più difficile, paradossalmente, è il delimitatore di fine comando SQL (una gran rottura di maroni).

Dentro i trigger ci sono due "set" di campi: OLD e NEW.
OLD.nomecampo è il valore "vecchio"; NEW.nomecampo quello che assumerà dopo il comando

Comunque ecco un esempio ("canonico")
codice:
delimiter |

CREATE TRIGGER pippo BEFORE INSERT ON tabella1
  FOR EACH ROW BEGIN
... qui ci metti quello che vuoi... update... delete... insert...
    INSERT INTO tabella2 SET a2 = NEW.a1;
  END;
|

delimiter ;
la prima e l'ultima istruzione (delimiter) in sostanza cambiano il delimitatore (la prima, ponendolo uguale a |), mentre l'ultima lo ripristina a ;

EDIT: nel tuo caso ci vuole il BEFORE UPDATE, ovviamente, e ci metterai un UPDATE della tabella2 sui dati della tabella1 usando il campo di join

In merito alla parte di scrittura nel db, beh dalla mia poca esperienza ,pensavo che una volta ottenuta la modifica derivante dalla tabella 1 con una query avrei potuto andare a scrivere i campi di mio interesse nel db del negozio ma coreggimi o illuminami (per favore), se sbaglio.
Il punto che non mi è chiarissimo è se il db del negozio risiede sullo stesso mysql.
Ossia se sono DUE db (due schema) diversi, sullo stesso server mysql, oppure due db diversi su due server mysql fisicamente distinti.
Nel primo caso => trigger.
Nel secondo master-slave ("magico") oppure (più semplicemente) "dump-e-restore" ("a mano")

Concludendo, anche a me ha dato molto fastidio il fatto che tu hai definito magicamente e subito ( e mi riferisco al risultato della macro analisi con i proprietari del db),
Non sono termini spregiativi, è slang informatico universalmente (o quasi) usati.

Non quindi nel senso "ti faccio vedere come sono capace di risolverti il problema", bensì "ti propongo una soluzione che funziona in slang informatico

"magicamente" = senza che debba fare nulla (non devi lanciare un comando, il db lo fa "magicamente", appunto)

"subito" = al momento stesso (per modo di dire, ovviamente una latenza c'è, ma parliamo di millisecondi) in cui viene modificato il dato. Non "ora modifichi la tabella1" e tra 10 minuti la modifica viene propagata "in qualche modo". "Ora" cambi la tabella1=>immediatamente la tabella2 rispecchia il cambiamento

Spero quindi sia chiarito l'equivoco.

ed a questo proposito pensavo semplicemente che una volta eseguito il primo step sul quale mi sono arenato, scrivessi i campi interessati nel db ogni 30 minuti prendendoli direttamente dalla
tabella 2.
Spero che si capisca come il trigger agisce "magicamente", e "subito" , mentre nel tuo caso "non magicamente" e "non subito".

L'alternativa è quella di "refreshare" (altro slang), ossia forzare l'aggiornamento di tutti i dati della tabella2 (le cui righe corrispondono con la tabella1), indiscriminatamente, ossia senza operare volta per volta sui dati cambiati (come fa un trigger), con una singola UPDATE.

Questa però non opera "subito" (deve essere avviata ogni TOT, ad esempio da un programma), e può essere lanciata "a mano" o "magicamente" (magicamente se hai mysql 5.5, che dispone di uno schedulatore interno in grado di eseguire ogni TOT minuti un certo comando).

In sostanza "ricopi" tutti i dati della tabella1 sulla 2, e buonanotte.

In merito al discorso del db remoto come slave del master locale, beh x me è fantascienza e sinceramente non credo che questa procedura meriti tante attenzioni(giuste per chi conosce il settore, ma per me che sono un normale tecnico sarebbe come arrampicarsi sugli specchi).
Anche qui in realtà non c'è nulla di "strano", niente "fantascienza", è solo "esperienza".

Puoi avere due server mysql distinti (uno qui, uno là) nel quale il primo assume il ruolo di master, mentre il secondo di slave.
"magicamente" (spero che qui si capisca dal contesto che significa "senza intervento dell'operatore) gli archivi del db slave vengono allineati a quello del master.

In questo modo non devi "a mano" propagare le modifiche tra l'uno e l'altro.

Non avvengono, però, normalmente "subito", a meno che non si imposti in maniera estremamente restrittiva la duplicazione (cosa che in generale NON si fa se due macchine sono collegate via internet, si può fare invece se sono collegate in LAN).

Detto tra di noi: la replicazione mysql non è un granchè, ha una caterva di difetti, però esiste, e magari ora (sia pure a grandi linee) sai che è possibile.
Magari un "domani" ti verrà comodo.
Spero di non esserti sembrato scortese e ti ringrazio anticipatamente,
Luca.
PS. sai io vivo in meridione da 3 anni è stò lottando x avere riconfermato un contratto di lavoro, quindi se con i tuoi consigli o dritte potresti aiutarmi te ne sarei infinitamente grato.
più modestamente posso provare a risponderti, nei limiti delle mie competenze e conoscenze