Limite numero query e MySql

[iaco74]

Ciao a tutti

Ho un area riservata e un database.
Il mio cliente dal suo gestionale aggiorna i dati nel database sul web.
I dati mi arrivano come file.dat.
Faccio il parsing dei dati li metto in degli array e poi con un paio di cicli costruisco la mia query che aggiornerà gli articoli di magazzino.

Il problema e' che la stessa query la ripeterò circa 2000 volte, cioè quanti sono gli articoli di magazzino.

Adesso ho testato tutto off-line e funge bene.

Mi domando quando sarò on-line, cosa succede se tale script viene eseguito in un momento di intenso traffico internet.
Potrei correre il rischio che mi rimanga a mezzo l'aggiornamento ?


Forse e' meglio spezzare la query in piccoli aggiornamente di 50 alla volta ?

Qualcuno ha già avuto problemi del genere ?

Ogni commento e suggerimento è gradito.

[piero.mac]

ho fatto dei fill-up di dati con update fino ad oltre 50.000 record alla volta... senza problemi. Pero' erano dati numerici.

Se non hai una pesante condizione di indici, che rallentano anche parecchio l'INSERT e l'UPDATE direi che non dovresti avere problemi.

[Tymba]

non puoi creare delle operazioni schedulate vero?

[iaco74]

Originariamente inviato da piero.mac
ho fatto dei fill-up di dati con update fino ad oltre 50.000 record alla volta... senza problemi. Pero' erano dati numerici.

Se non hai una pesante condizione di indici, che rallentano anche parecchio l'INSERT e l'UPDATE direi che non dovresti avere problemi.

Indici non ce ne sono......
Anche in questo caso sono solo dati numerici 16 campi lunghi quattro alcuni sono come integer altri come varchar.

A proposito, come integer e' piu' veloce l'aggiornamento ?

Invece ho un sacco di problemi anche in locale con "Select" tra due tabelle diverse entrambe di 2000 righe ciascuna.
La query va a verificare di prendere i record che abbiano 3 condizioni uguali.
E' lentissimo... se poi ci metto "ORDER BY" va in timeout la query(30sec).
Per questa operazione sto creando un sistema che seleziona e aggiorna 50 record alla volta.

Suggerimento in merito ?

[iaco74]

Originariamente inviato da Tymba
non puoi creare delle operazioni schedulate vero?

Ti puoi spiegare meglio ?

[piero.mac]

Originariamente inviato da iaco74
Indici non ce ne sono......
Anche in questo caso sono solo dati numerici 16 campi lunghi quattro alcuni sono come integer altri come varchar.

A proposito, come integer e' piu' veloce l'aggiornamento ?

Invece ho un sacco di problemi anche in locale con "Select" tra due tabelle diverse entrambe di 2000 righe ciascuna.
La query va a verificare di prendere i record che abbiano 3 condizioni uguali.
E' lentissimo... se poi ci metto "ORDER BY" va in timeout la query(30sec).
Per questa operazione sto creando un sistema che seleziona e aggiorna 50 record alla volta.

Suggerimento in merito ?

come primo suggerimento .... dai qualche info in piu', posta la query quantomeno....

[ringo_mato]

Originariamente inviato da iaco74
Ti puoi spiegare meglio ?

Crontab http://forum.html.it/forum/showthrea...hreadid=310412

[iaco74]

come primo suggerimento .... dai qualche info in piu', posta la query quantomeno....

Ok giusto

Ho un area riservata e un DB mysql con varie tabelle.
La più importante "articoli" contiene gli articoli di magazzino.
La seconda tabella "agg_articoli" e' vuota c'e' solo la struttura.
Vengono sparati due file di aggiornamento dati uno per l'estate e uno per l'inverno, dal gestionale della azienda via ftp.
Poi l'utente del pannello di controllo va a fare determinate operazioni.
Ammettiamo di lavorare sull'estate (dato che ci siamo);
Il tracciato record e' lungo circa 2000 righe.....
E' un file.dat:

*;13042     ;4100      ;040;38:0000;40:0000;42:0000;44:0000;46:0000;48:0000;50:0000;52:0000;54:0000;56:0000;58:0000;60:0000;1

Adesso io ho impostato una logica cosi per aggiornare.
Dato che devo verificare tutte le volte che ho un aggiornamento se ci sono nuovi articoli, se ci sono articoli a zero, o se ci sono esistenze da modificare.

Premesso che un record principalmente è formato da "modello,tessuto,colore, ecc" e che posso avere più modelli fatti in tessuti diversi ed in colori diversi :
Es:

modello 301 tessuto 4000 colore 010
modello 301 tessuto 4000 colore 020
modello 301 tessuto 5000 colore 010

Per me sono 3 record diversi nel DB.

(puo' sembrare strano ma siccome poi a tali dati sono aggiunte immagini dei capi ed immagini dei tessuti, e i dati saranno presentati in flash, era meglio avere una struttura cosi)

Detto questo appunto parso il tracciato record, e vado a popolare la tabella agg_articoli.
Nessun problema con INSERT scorre benino, almeno offline.

Una volta fatto questo in un altra pagina php vado a fare l'aggiornamento dei record.
Spezzo l'aggiornamento in tre fasi :

inserimento dei record nuovi

cancellazione di quelli con esistenza zero(nel tracciato record finale avrò anche il totale per taglia, cosi questa parte sarà più veloce)

aggiornamento per quelli che avranno l'esistenza per taglia e colore cambiata.

Per inserire i nuovi record confronto la tabella per cosi dire temporanea agg_articoli con la tabella "buona" articoli.
Dato che devo confrontare 3 condizioni (modello,tessuto,colore) la mia query potrebbe essere questa :

$sql="SELECT * FROM agg_articoli, articoli WHERE agg_articoli.modello=articoli.modello AND agg_articoli.tessuto = articoli.tessuto AND agg_articoli.colore = articoli.colore";

Se per caso provassi a mettere un "ORDER BY" mi va in timeout in locale (30sec).

Curiosità: perche se invece di mettere "SELECT * FROM agg_articoli" mettessi "SELECT modello FROM agg_articoli" mi da questo errore "ambigus column modello".

Detto questo pensavo come detto sopra di spezzare questa query in pezzi da 50 operazioni l'una con un limit.

Spero di essermi spiegato bene, non era facile.

[iaco74]

Originariamente inviato da ringo_mato
Crontab http://forum.html.it/forum/showthrea...hreadid=310412

Pillola interessante, grazie per la segnalazione.
Non credo che sul mio hosting per questo sito, di avere la possibilità di usare un sistema del genere, ma per progetti futuri mi informerò prima, sarebbe una bella comodità fare tutto a tempo.

[piero.mac]

Di primo acchito si evidenzia l'esistenza di un problema. hai alcuni campi delle due tabelle con lo stesso nome.

fai attenzione perche' i campi con nomi uguali si sovrascrivono nella select. Sarebbe opportuno dare nomi di campo diversi alle due tabelle oppure usare degli alias.

Personalmente preferisco dare nomi univoci, magari anche solo premettendo un prefisso ai campi come hai fatto per la tabella.

puo' essere che il problema dell'order by sia dovuto a queste omonimie.