php-mysql / più insert in una sola exec: vantaggi? | SQL & MySQL

Topic: Pubblico - Composto da 5 Posts di 3 Utenti.

05 Luglio, 2010 08:07 #1
re-verse
Moderatore

re-verse
Registrato: Jul, 2008
Posts: 312
Offline

Buongiorno a tutti :) ... ho un dubbio su una cosa che vorrei fare, ma non so se rappresenta un effettivo vantaggio, ve la illustro:

Ho una serie di “insert” che andrebbero eseguite in una transazione, ma purtroppo ho tabelle non innoDb e non posso cambiarle – quindi per la transazione: nisba!

Allora ho eseguito un semplice controllo dopo ognuna di queste insert in modo tale da effettuare una ‘pseudo-rollback’ in caso di errori.

Il mio dubbio è il seguente: le insert che devo eseguire sono 4 (non eccessivamente lunghe): se le eseguissi in un unico statement, avrei qualche vantaggio in termini di controllo sull’errore e magari anche in termini di prestazioni? ... e per ampliare un pò il campo di applicazione: in genere, è meglio eseguire le query singolarmente, oppure raccogliere tutti i dati ed eseguirle in blocco?

Grazie a chi voglia approfondire con me la questione :) Un saluto a tutti :)


Salvatore DC

La mente è come un paracadute: funziona solo se si apre. A.Einstein.

05 Luglio, 2010 10:58 #2
root
Amministratore

root
Registrato: Jul, 2008
Posts: 60
Offline

Bentornato! :)

Molto interessante il tuo quesito. Il primo punto, cioè la questione pseudo rollback, è purtroppo la più triste. Nel senso che se sei obbigato a mantenere uno storage engine non transazionale sono dolori. Nel senso che devi risolverti la cosa a livello applicativo e credo che tu, come me e molti altri, avresti preferito che MySql lavorasse per te. Per quanto riguarda il secondo punto, so dirti per certo che in termini di benefici prestazionali è di sicuro meglio raggruppare le insert. Per la questione della gestione dell’errore non credo che la situazione sia migliorabile. Per quanto riguarda la questione generale blocco/singolo “sembra” che la soluzione sia sempre più efficacie ed efficiente.

Più in generale ancora, il discorso è molto ampio quando si lavora con un db in ambito applicativo. Dal tuo post non riesco a dedurre se è anche il tuo caso. Di solito, in contesti come le applicazioni web, io consiglio di affidarsi quando possibile a un framework ORM o similiare. Il punto è che, se non si hanno partiocolari specifiche tecniche, un progetto beneficia molto in termini di produttività dall’utilizzo di uno strumento specifico per sgravarsi il peso di gestire a livello applicativo problemi che di natura applicativa non sono.

A presto

05 Luglio, 2010 11:22 #3
re-verse
Moderatore

re-verse
Registrato: Jul, 2008
Posts: 312
Offline

Ciao Root, il contesto in cui mi trovo ad operare è in questo caso sia applicativo(backOffice) che pubblico(ecommerce).

In particolare vorrei prevenire alcune situazioni che si potrebbero creare con azioni simultanee sulle stesse tabelle dal momento che le chiavi devono rimanere ovviamente allineate. Purtroppo non posso effettuare lock, nè come detto prima cambiare engine, per cui gli unici controlli che posso fare non possono essere preventivi e andrebbero fatti a livello applicativo.

Ovviamente è già tutto fatto… ecco… mi chiedevo se non fosse possibile migliorare :)

Applicare un ulteriore strato applicativo come un framework ORM non credo sia la cosa più leggera di questo mondo… anche perchè questo genere di controllo mi serve effettivamente in una singola azione dell’intero sito, per cui sarebbe un pò sprecato il framework.

Beh, credo che lascerò i controlli su ogni singolo blocco :) in definitiva per adesso con tutti i test di concorrenza non ho riscontrato alcun errore :)

Grazie mille per la risposta, mi ha offerto qualche spunto in più per la riflessione:) A presto :)


Salvatore DC

La mente è come un paracadute: funziona solo se si apre. A.Einstein.

05 Luglio, 2010 21:02 #4
g2d
Moderatore

g2d
Registrato: Jul, 2008
Posts: 867
Offline
Segui g2d su Twitter!

Ciao mem

come stai ? è un bel pò che nn ci si sente …

una sola curiosità… perchè pensi di non poter effettuare il lock delle tabelle ? mi rendo conto che parlando di MyISAM dovresti effettuare il lock sull’intera tabella e non sulla riga come InnoDB, però ci sono un pò di varianti/opzioni… magari qualcuna fa a caso tuo.

In ogni caso ti suggerisco questi due approfondimenti:

http://dev.mysql.com/doc/refman/5.1/en/internal-locking.html

e quest’altro che come tutti gli articoli del MySQL Performance Blog è sempre eccezionale

http://www.mysqlperformanceblog.com/2006/06/17/using-myisam-in-production/

Facci sapere se hai trovato una soluzione migliore, il tuo è un problema molto comune

Saluti algweb


Un tempo ero algweb ora sono g2d

06 Luglio, 2010 08:07 #5
re-verse
Moderatore

re-verse
Registrato: Jul, 2008
Posts: 312
Offline

Hey Alg!! :) già, purtroppo ci sono periodi in cui mi faccio prendere dagli impegni e mi resta poco tempo per … diciamo per tutto il resto :)

Per quanto riguarda la lock… sarebbe un pò complicato poichè lavoro su tabelle che vengono utilizzate contemporaneamente da più applicativi: su alcuni di questi posso intervenire (quindi no problem), su altri no poichè sono brodaglie.pacchettizzate.visualbasic.vattelapesca… e siccome già una volta ho avuto problemi con qualche lock, non mi sento tanto sicuro a reintrodurre la questione.

Le tabelle interessate dalla insert sono 5, tutte con chiave autoincrement. Attualmente la soluzione che ho adottato è la seguente:

(prelevo un max della chiave da tutte le tabelle e mi tengo il (max maggiore)+1 per le insert);
(inserisco su tabella #1);
(se ci sono errori)=>(elimino record inserito da tabella #1);(termino);
(inserisco su tabella #2);
(se ci sono errori)=>(elimino record inserito da tabella #1,#2);(termino);
...
(inserisco su tabella #n);
(se ci sono errori)=>(elimino record inserito da tabella #1,#2,...,#n)(termino);

Tutto questo in un ciclo di 5 tentativi.

Beh, sono sicuro che si possa fare di meglio :) ma al momento non mi vengono altre idee :)

Ultima modifica 11 Luglio, 2010 01:16 di re-verse


Salvatore DC

La mente è come un paracadute: funziona solo se si apre. A.Einstein.

Condividi su:

Loggati o Registrati per replicare