Ho quindi deciso di farmi in casa un benchmark che, sebbene effettuato in modo piuttosto grossolano e rapido ha dato dei risultati abbastanza netti.
Il test è stato eseguito con le seguenti condizioni (da qui capirete che è abbastanza spartano come benchmark):

• Windows 7 64 BIT
• mysql 5.1.x 64 BIT per Windows
• .NET Framework 4.0
• Utilizzato Cassini al posto di IIS
• DevArt versione 6.30.185.0
• mysql Connector NET versione 6.4.4

In pratica ho lanciato due procedure separate con la mia macchina nelle stesse condizioni di lavoro e a distanza di pochissimo tempo, quindi applicativi aperti, musica che suona e via discorrendo

Il test era suddiviso in due componenti, l’esecuzione di 1.000 query su una tabella con campo indicizzato passandogli un valore randomico e l’inserimento di 1.000 record sempre con valori randomici.
In particolare l’inserimento prevedeva il COMMIT ad ogni STATEMENT perché altrimenti non si notava alcuna differenza di performance tra i due drivers.

Di seguito i risultati nudi e crudi:

mysql (utilizzo 27%/30% CPU poi sceso in insert a 13%/15%) 6.4.4

• Data avvio select: 30/12/2011 18:12:03
• Data fine select: 30/12/2011 18:12:31
• Data avvio insert: 30/12/2011 18:12:31
• Data fine insert: 30/12/2011 18:12:43

DevArt (utilizzo 27%/31% CPU in insert a 13%/17%) 6.30.185.0

• Data avvio select: 30/12/2011 18:13:21
• Data fine select: 30/12/2011 18:13:38
• Data avvio insert: 30/12/2011 18:13:38
• Data fine insert: 30/12/2011 18:13:44

Tempo SELECT MySQL: 28 secondi
Tempo SELECT DevArt: 17 secondi

Tempo INSERT MySQL: 12 secondi
Tempo INSERT DevArt: 6 secondi

Direi che è abbastanza chiaro che, a parte una lieve differenza nell’utilizzo della CPU (in favore del driver mysql Connector NET meno esoso), la velocità di esecuzione sia delle SELECT che delle INSERT è nettamente in favore di DevArt.

Morale, bene così, almeno non ho toppato driver per un importante progetto che sto sviluppando!

Qualora per motivi di spazio o banalmente convinti che la /tmp non sia necessario renderla di ampie dimensioni, potrebbe accadere che durante certe operazioni molto pesanti su tabelle con quantitativi di record notevoli, il sistema esaurisca lo spazio nella partizione temporanea durante la fase di elaborazione dati e scrittura di una tmp table, proprio su questa partizione.

La query abortira’ con un messaggio del tipo no space left on device o qualcosa del genere.

In tal caso andra’ allargata la partizione tmp di sistema (o dove si appoggia mysql) o in alternativa cambiato il path (che deve essere scrivibile dallo user “mysql“), fermato il servizio mysql e riavviato.

Segnalo una problematica di sicurezza abbastanza importante per coloro che utilizzano adodb utilizzando il driver mysqli (le nuove funzioni di connessione con mysql native in php 5).

In sostanza le nuove funzioni mysqli consentono mediante la seguente funzione: mysqli_multi_query di poter eseguire più statement SQL in mysql come ad esempio:

SELECT * FROM TBL1 WHERE id = 1; DROP table TBL2;

Questa query utilizzando le vecchie librerie mysql (es. mysql_connect) dava errore.
La possibilità di eseguire più query SQL è supportata su mysql 5.0.x anche da command line, non saprei se anche vecchie versioni lo consentivano.

Questo significa che se per esempio utilizziamo in php una query del tipo:

$sql = “SELECT * FROM tbl1 WHERE id = $_GET['id']“; // (Premesso che venga come minimo fatto l’escape dei caratteri come ‘ o “)

Possiamo rischiare che qualche burlone passi in GET il seguente valore:
“1; DROP TABLE tbl2;”
Il che comporterebbe che l’SQL eseguito sia:

SELECT * FROM TBL1; DROP table TBL2;

Di fatto quindi con AdoDB con driver mysqli, la seconda query viene effettivamente eseguita.

Diventa quindi essenziale fare un controllo sull’input dell’utente per $_GET['id']. Ad esempio verificando che sia un numero intero.

La soluzione più rapida è quella di cambiare la connect di AdoDB dicendogli di usare il driver mysql anziché mysqli, la soluzione migliore e da fare comunque resta in ogni caso il filtraggio di tutti i dati in input.

http://punto-informatico.it/2494271/PI/News/mysql-51-una-falsa-partenza.aspx

E qui l’articolo ufficiale in lingua inglese di Michael Widenius ex CTO della mysql AB acquistata tempo fa da SUN.

http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html

Io per adesso rimango sul 5.0 sul quale onestamente ho avuto pochi problemi.

Vediamo di seguito l’utilizzo dei TRIGGER in mysql 5, se non dico male infatti sino alla versione 5.0.x i TRIGGER su mysql non erano disponibili.

Prima di tutto, a cosa servono i TRIGGER? I TRIGGER hanno il principale scopo di automatizzare determinate operazioni sul database all’occorrenza di determinati eventi come INSERT, UPDATE o DELETE.

Il modo con cui creare un TRIGGER è piuttosto semplice:

CREATE TRIGGER setnoprice BEFORE UPDATE ON prodotto
FOR EACH ROW
BEGIN
IF NEW.online = ‘no’ THEN
SET NEW.prezzo = 0;
END IF;
END

Analizziamo cosa fa di fatto questo TRIGGER, al di là della sintassi:

Ipotizziamo di avere ad esempio un sito di e-commerce dal quale i prodotti sono acquistabili esclusivamente quando il loro prezzo è maggiore di zero, mentre sono online altri prodotti per il quale esiste una presentazione ma l’acquisto può essere fatto contattando l’ufficio commerciale e non viene esposto il prezzo.

Conseguentemente quando un prodotto va offline è automatico che non sia più vendibile. La soluzione più classica e semplice (apparentemente) è quella di gestire l’operazione direttamente da backoffice dell’applicativo in modo automatico o peggio ancora di delegare al gestore del backoffice il fatto di resettare a zero il prezzo quando un prodotto va offline.

[Piccolo inciso, so benissimo che potrebbe essere bloccato l'acquisto oltre che per prezzo a zero anche nel caso il flag online sia off, così come so che il prodotto non sarebbe nemmeno visualizzato, ma un'esempio lo dovevo fare... ]

Entrando nel dettaglio mysql applicando questo TRIGGER si preoccupa di eseguire PRIMA [BEFORE] dell’azione UPDATE [solo update quindi] la verifica se online diventerà uguale a off e in tal caso forza il nuovo valore di prezzo a zero.

In sostanza il TRIGGER va a sostituire quelle operazioni automatiche che normalmente vengono delegate all’applicativo.

Per maggiori informazioni potete consultare direttamente il manuale di mysql alla pagina relativa ai TRIGGER.

Durante la ricerca di qualcosa di ben funzionante mi sono imbattuto in:

DB Convert for mysql and PostgreSQL 2.0.x

Questo software consente in modalità trial di importare solo 10 record per tabella. E’ sufficiente nel caso sia necessario solo ripristinare la struttura, nel caso import di dati invece risulta insufficiente.

Per poter disporre delle funzionalità complete è sufficiente acquistarlo ad una cifra ragionevole di 69 dollari.

Il software dopo l’installazione consente una comoda migrazione di tutto quanto. La migrazione può essere bidirezionale.

La stessa software house propone altri tool come il sync.

Sono disponibili inoltre migrazioni da svariati altri database.

Per maggiori informazioni: http://www.dbconvert.com

PREMESSE AL PROBLEMA

• mysql versione > 4.1.x
• Tipo di encoding delle pagine web php utf8

DESCRIZIONE PROBLEMA

La situazione problematica nasce nel momento in cui abbiamo un sito web che deve gestire caratteri extra latini, per esempio nel mio caso ho affrontato questo problema dovendo realizzare un sito in lingua russa, ovvero utilizzando il cirillico.
Il mio approccio alla situazione e’ stato quello di realizzare TUTTE le pagine web con codifica utf8 e database, tabelle e campi di testo utf8 a loro volta.
La cosa che mi ha fatto impazzire e capirci veramente poco per diverso tempo e’ che se io inserivo nel database caratteri cirillici come ad esempio (Ã�ŸÑ€Ã�¸Ã�²Ã�µÑ‚ – ciao) e da PhpMyADMIN (di seguito PMA) vedevo male, idem il dump, mentre quando tiravo su i dati da applicativo tutto funzionava a meraviglia.
Capitava l’inverso con PMA, ovvero se inserivo in cirillico su PMA e visualizzavo da PMA tutto bene, via applicazione niente.

SOLUZIONE

Prima di tutto vi invito a leggervi questa parte di manualistica online di mysql, CHARSET.

Sostanzialmente sui server mysql di sistemi di hosting italiani (ma credo anche americani) e comunque in generale, l’impostazione del default_character_set è impostata a latin1.
Ma anche qualora sia impostata ad utf8 quando via script php ci connettiamo al database mysql la nostra sessione di default (nonostante la pagina sia encodata utf8) sarà attivata con character set latin1, cosa succede quindi, che i dati e le query che inviamo sfasano e il sistema memorizza erroneamente i dati.

Di fatto il comportamento giusto lo ha PMA, dobbiamo cercare quindi di emularlo.
Per farlo basta di fatto lanciare dopo ogni connessione la seguente query: SET NAMES utf8
Così facendo la connessione tra client e server sarà UTF8.

CONCLUSIONE

Per concludere possiamo dire che per siti che trattano lingua standard europee come italiano, inglese, francese etc… possiamo avere tutto il DB latin1, connessione client server latin1 ed encoding ISO-8859-1

Nel caso di siti con cirillico, arabo etc… utilizziamo tutto il database UTF8, encoding delle pagine UTF8 e soprattutto dobbiamo eseguire per sicurezza la query sopra indicata dopo ogni connessione con mysql.

Mi scuso per non essere stato molto chiaro in alcuni punti, purtroppo questo argomento è complesso e fastidioso…
Se avete suggerimenti sono benvenuti.

Ciao a tutti. Max
info[AT]massimo-caselli[DOT]com