Topic: Pubblico - Composto da 5 Posts di 3 Utenti.
| 05 Luglio, 2010 08:07 | #1 | ||
|---|---|---|---|
|
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 | ||
|---|---|---|---|
|
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 | ||
|---|---|---|---|
|
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 | ||
|---|---|---|---|
|
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 | ||
|---|---|---|---|
|
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); 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