Lentezza INSERT in MySql

[danilolc]

Ciao a tutti,

vi pongo un problema che ho in fase di inserimento records in un database MySql con codice PHP: praticamente il codice deve effettuare "n" INSERT in un ciclo FOR, e questa operazione impiega molto tempo a completarsi (quasi un minuto!);
questo è il codice che uso :

for ($a=1; $a<=$qta; $a++){
$wmsid=creoid($database_myconn, $myconn, "gia_id", "giacenze");
$sqlins="INSERT INTO giacenze (gia_id, gia_codice, gia_societa,
gia_pallet2, gia_lunghezza, gia_larghezza,
gia_datacarico, gia_locazione, gia_status, gia_picker)
VALUES ($wmsid, '$codprodotto', '$societa',
$numbarcode, $lunghezza, $larghezza,
'$datacarico', '$locazione', 'd', $picker)";
$risultato = mysql_query($sqlins, $myconn);
}

Alcune note :

- la chiave primaria della tabella "giacenze" (quella che devo aggiornare) NON è autoincrementante (ecco il motivo del richiamo alla funzione "creoid" che mi ritorna l'id da salvare)
- le tabelle sono di tipo MyISAM

Qualcuno può aiutarmi a risolvere i miei problemi di lentezza ?

Grazie in anticipo a tutti!

[Leilond]

La lentezza è tutta dentro la mancanza della chiave autoincrementata. Quel problema ti obbliga in pratica a fare una select per ogni insert, cosa che inoltre non ti puoi esimere dal fare perchè non sai se tra un insert e l'altra c'è stato qualche altro script che ha inserit, e cosa che comunque non ti protegge dai duplicati, perchè se due script (o lo stesso script caricato da due utenti connessi) usano più o meno contemporaneamente "creoid", otterranno lo stesso risultato creando record con chiave duplicata
Perchè non aggiungere un campo auto_increment?????

[danilolc]

sospettavo qualcosa del genere...

il fatto è che ho scelto di non usare una chiave autoincrementante perchè la stessa chiave la uso poi in altre tabelle... mi sa che mi sono un pò "incartato" da solo; provo a "trasformare" la chiave in autoincrementante e verifico le performance.

grazie.

[Leilond]

E' normale usare una chiave auto_increment di una tabella come elemento di altre tabelle, ma in quelle tabelle quella chiave non sarà auto_increment

Una cosa del genere
Tabella Utenti
id (auto_increment)
nick
nome
cognome
mail

Tabella Messaggi
id (auto_increment)
user_id (non auto increment)
messaggio

In questo modo quando fai una insert nella tabella Utenti avrai la certezza della chiave univoca id. Tale chiave viene poi usate per valorizzare user_id della tabella Messaggi che a sua volta avrà la propria chiave auto_increment da usare per il reperimento dati (dove necessario)

[danilolc]

Il fatto è che sulla seconda tabella la stessa chiave è anche qui primaria; inoltre facendo la chiave incrementante non copre i "buchi" che si verificano quando elimini un record.

comunque è ovvio che se questo mi porta a problemi di lentezza riferifico il tutto...

[Leilond]

I buchi sono totalmente INSIGNIFICANTI e non devono essere considerato un problema

Inoltre, devi differenziare il concetto di chiave UNIVOCA e chiave PRIMARIA

Una tabella può avere una chiave ESTERNA (ovvero la chiave primaria di un altra tabella) e definire questa come chiave UNIVOCA ma non come chiave PRIMARIA
Questo risolverebbe il problema CONCETTUALE

Inoltre tieni a mente questo
Se due tabelle hanno la stessa chiave PRIMARIA allora è il caso che consideri l'opportunità di FONDERLE in un unica tabella
Se proprio non vuoi, per qualche motivo che ora magari mi sfugge, puoi creare la seconda tabella SENZA chiave primaria ma con la chiave UNIVOCA. Quando devi inserire elementi in entrambe le teabelle fai prima la insert nella TABELLA1, recuperi l'id inserito con la funzione mysql_insert_id() e usi quel valore per inserirlo nella TABELLA2. Questo ti protegge al 100% da qualsiasi duplicato, anche se rimango dell'idea che le due tabelle dovrebbero fondersi

[danilolc]

Originariamente inviato da Leilond
Se proprio non vuoi, per qualche motivo che ora magari mi sfugge, puoi creare la seconda tabella SENZA chiave primaria ma con la chiave UNIVOCA. Quando devi inserire elementi in entrambe le teabelle fai prima la insert nella TABELLA1, recuperi l'id inserito con la funzione mysql_insert_id() e usi quel valore per inserirlo nella TABELLA2. Questo ti protegge al 100% da qualsiasi duplicato, anche se rimango dell'idea che le due tabelle dovrebbero fondersi

No, per come funziona l'applicazione non posso fondere le due tabelle; seguirò invece il consiglio della chiave UNIVOCA ma non PRIMARIA.

Grazie!

[gianf_tarantino]

Hai scritto:
Il fatto è che sulla seconda tabella la stessa chiave è anche qui primaria; inoltre facendo la chiave incrementante non copre i "buchi" che si verificano quando elimini un record.


Innanzitutto solo nella tabella dove ti crei l'id, allora questo deve essere di tipo autoincrement. Nelle altre, puoi, benissimo avere lo stesso id come chiave primaria, ma NON deve essere di tipo autoincrement.
Nel momento in cui fai un inserimento, prima lo fai nella tabella dove c'è l'autoincrement, così ti genera l'id, lo prelevi e lo usi per l'inserimento nelle altre tabelle.

I "buchi" a cui accennavi si risolvono nel creare la relazione CHIAVE ESTERNA-CHIAVE PRIMARIA tra le varie tabelle. Nel nostro caso tutte le tabelle con id che non è autoincrement saranno in relazione con la chiave primaria della tabella dove hai l'autoincrement. In tal modo ogni volta che elimini un record dalla tabella dove hai l'autoincrement, MySQL automaticamente ti eliminerà tutti quei record nella altre tabelle che utilizzano quello stesso id che hai cancellato.

Ciao.

[gianf_tarantino]

Ohps, ti aveva già risposto Leilond.

[Leilond]

Un'unica precisazione
Non tutti gli host concedono la possibilità di creare tabelle "INNODB" e quindi "chiavi esterne"
In quel caso dovrai occuparti di cancellare MANUALMENTE tutti i record delle tabelle "legate" quando cancelli dalla tabella primaria

@danilolc
Tu dici

No, per come funziona l'applicazione non posso fondere le due tabelle

Ho la sensazione che è l'applicazione ad essere disegnata senza considerare la normalizzazione del database e che quindi dovrebbe essere questa ad essere "migliorata"
Comprendo però che FORSE sei già troppo in là per correggere questo probabile errore di progettazione