PHP/MySQL Transactions…

Ci son cose che proprio non digerisco di SQL, una di quelle è la clausola INSERT e soprattutto come viene gestita in MySQL (via PHP).

Ormai tutti i database di questo mondo permettono di avere tabelle con indici/chiavi numerici autoincrementanti (che non sono standard) eppure la loro implementazione della INSERT spesso viene gestita come una “procedura” e non come una “funzione“: inserisci qualcosa (indice nuovo e autoincrementato) e poi ti tocca fare subito un’altra query (o invocare una funzione wrapper apposita come mysql_insert_id()) per sapere l’ID del record appena inserito (LAST ID).

In una applicazione web seria, con molti inserimenti concorrenti, fra la INSERT e la SELECT (che recupera l’ultimo ID inserito) può inserirsi qualche altra operazione (magari un altro inserimento) che fa cambiare erroneamente il LAST ID…

Una semplice soluzione è rappresentata dalle cosiddette transazioni (secondo SQL e nella documentazione di MySQL).

Si tratta di una serie di query, opportunamente raggruppate, che viene processata “atomicamente” (cfr. lettera “A” delle cosiddette “proprietà ACID” nel campo dei database), ossia come se fosse un’unica operazione.

mysql_query(‘START TRANSACTION’);

//Svariate query (INSERT, RECUPERO ULTIMO ID INSERITO, UPDATE, …)
// [...]

//Verifica prima della chiusura
if($TUTTO_OK)
{
    // confermiamo l’intera transazione
    mysql_query(‘COMMIT’);
}
else
{
    // annulliamo l’intera transazione
    mysql_query(‘ROLLBACK’);
}

Il procedimento è semplice:

• si apre la transazione;
• vengono scritte le query da eseguire “in blocco”
• si conferma l’intero blocco e le relative operazione (COMMIT) o si annullano (ROLLBACK)

Non si sa nulla circa possibili ottimizzazioni a livello di “blocco di query” anche se è possibile che l’ottimizzatore di query interno a MySQL riesca a operare in maniera più agevole e con una migliore granularità (un conto è ottimizzare n query in un colpo, un colpo è invece dover fare n ottimizzazioni su una query per volta).