Inserimento in un db del risultato di una join

[archivio]

Ciao a Tutti,
mi trovo ad avere 2 tabelle praticamente uguali ma con nomi diversi, una contiene la diponibilità degli articoli presenti nel db a e l'altra invece ha una disponibilità differente essendo la prima un magazzino formitore e la seconda un negozio di rivendita.

Il mio problema è il seguente:

le due tabelle devono confrontarsi ogni tot tempo e quando in base all'id articolo vi sono delle differenze nelle quantità tra la tabella 1 e la tabella 2, la prima deve andare a scrivere la propria quantità nella tabella 2, di consenguenza la tabella 2 deve andare ad aggiornare i suoi nuovi valori all'interno di un db corrispondente che non è lo stesso di origine delle 2 tabelle.

Ho visto l'estistenza del comando join che credo faccia al caso mio ma non riesco ( a causa della mia poca espeienza), a comprendere come unire i valori delle 2 tabelle contenenti le quantità in un'unico valore e farlo quindi scrivere nel db.

Sono disperato è da giorni che mi scervello non riuscendone a cavare un ragno dal buco.

Grazie a chiunque possa consigliarmi o aiutarmi

[deleted_29]

mi sembra un pochino "cervellotico".
Se non ho capito male hai

tabella1(id_articolo; quantita)
tabella2(id_articolo; quantita)
tabella3(id_articolo; quantita)

e vuoi che

PER OGNI tabella1.id_articolo=tabella2.id_articolo 
tabella2.quantita=tabella1.quantita

e poi

PER OGNI tabella2.id_articolo=tabella3.id_articolo 
tabella3.quantita=tabella2.quantita

ho capito bene?

[archivio]

Ciao franzauker,

Vorrei innanzitutto Ringraziarti per il tuo interessamento ed in secondo luogo vorrei cercare di essere più chiaro anche se mi pare che tu abbia bene inteso qual'è la problematica.

In sintesi ho un'applicazione gestionale che che si occupa della gestione del magazzino di un formitore appoggiandosi su un server sql, tra le centinaia di tabelle presenti, due di queste sono identiche come campi, una è usata dal magazzino per la sua gestione degli articoli ed una è dedicata ad un negozio che collegandosi in remoto al gestionale sfrutta le pontenzialità dello stesso per la fatturazione etc.
Mi è stato richiesto di far si che quando cambiano le quantità di un articolo nella tabella del gestionale le stesse quantità vengano riportate automaticamente nella tabella del nogozio, la quale a sua volta dovrà tramite script php o file beach trasmetterle al db del negozio situato in un'altra posizione remota.
In fine mi è stato richiesto che lo stesso aggiornamento parta contestualmente alla variazione della quantita di articoli nella prima tabella (quella del magazzino), indicizzata per id.

Spero di essere riuscito a spiegare la problematica da risolvere e ti ringrazio anticipatamente.

[deleted_29]

Originariamente inviato da archivio
Mi è stato richiesto di far si che quando cambiano le quantità di un articolo nella tabella del gestionale le stesse quantità vengano riportate automaticamente nella tabella del nogozio, la quale a sua volta dovrà tramite script php o file beach trasmetterle al db del negozio situato in un'altra posizione remota.

Queste sono due cose diverse, anche se non poi così tanto.

Se non ho capito male vuoi che "magicamente" i campi della tabella2 siano allineati a quella della tabella1, quando c'è una variazione nella tabella1.

Soluzione: un trigger.
Non molto efficiente, ma funziona.
La modifica di un campo della tabella1 provoca la modifica del relativo campo (con lo stesso id) della tabella2, "magicamente" e "subito".

Un trigger mysql è uno "script" (uso termini un pochino semplicistici, ma spero si capisca) che viene automaticamente attivato (nel tuo caso) prima o dopo la modifica di un record, e lo puoi (/devi) associare ad una tabella.
---
La seconda richiesta "propaga" le modifiche su un altro db.
Non mi è chiarissimo se in questo db la tabella "3" deve essere identica alla tabella "2", oppure no (oppure no ad esempio se ha più righe).
Caso "sì": => ti basta un mysqldump ed un brutalissimo restore fatto "ogni tanto"

Oppure potresti usare il db remoto come slave del master locale (ma, senza offesa, visti i dubbi palesati non mi "lancerei" in tali "avventure")

[archivio]

ciao franzauker,

Si, scusami se non sono riuscito ad essere molto chiaro.
E' palese che la mia esperienza in sql non è molta, del resto non mai avuto modo e necessità di rafforzarla.

In merito alla prima parte della tua risposta altre a ringraziarti del consiglio in merito al trigger ti confesserò che non ho la ben che minima idea di cosa sia...

Ma, se potresti postare un piccolo esempio te ne sarei grado, poi penso che ricercando e confrontandomi un po con ex colleghi(magari), riuscirei a venirne fuori alla grande.

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.

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),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.

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).
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.

[deleted_29]

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")

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

[archivio]

C'è un Ringraziamento Dovuto,
Un Ringraziamento Sentito ed un Ringraziamento dal Cuore

I due db sono su server diversi, uno 2003 e l'altro linux. Quindi in sintesi per risolvere il mio problema dovrei aggiornare il tabella 2 al cambiamento di tabella 1 ed usare il codice che mi hai suggerito con l' update dei campi che mi interessano ogni tot tempo ?

[deleted_29]

Originariamente inviato da archivio
Quindi in sintesi per risolvere il mio problema dovrei aggiornare il tabella 2 al cambiamento di tabella 1 ed usare il codice che mi hai suggerito con l' update dei campi che mi interessano ogni tot tempo ?

Se indichi qual'è la struttura delle tabelle 1 e 2, e quali campi vuoi aggiornare, ti metto il trigger "giusto" e come crearlo.

---
Mentre per la tabella3 ("remota") non hai precisato se devi sovrascriverla coi dati della tabella2 (in sostanza cancellando la tabella3 sostituendola con la tabella2), ogni TOT minuti, oppure se vuoi "fonderla".

Se vuoi "fonderla" (nel senso che la tabella3 ha più righe della tabella2) non si può usare la tecnica "dumpa-e-restora", perchè ne perderesti il contenuto (della tabella3).
Chiarito questo punto si può pianificare come effettuare

[archivio]

Ok
tiro giù le tabelle e ti mando il tutto.
Grazie