Giù la maschera, MySql

Qualche tempo fa mi stavo chiedendo se il grande clamore intorno al database MySql fosse qualcosa di concreto oppure soltanto un gran polverone con poca sostanza. Ho infatti avuto la necessità di sviluppare un’applicazione ed avevo volevo utilizzare uno strumento per lo store dei dati strutturati alternativo a quello già in uso.

Per cui il mio primo pensiero è andato al database Mysql. Semplice da usare, gratuito, grande quantità di forum e documentazione in rete, eccetera, eccetera.

Decido quindi di procedere con qualche test preliminare installando la versione 5.6 del database MySQL, disponibile al momento.

Sono subito cominciati ad emergere alcuni importanti problemi che mi hanno costretto a riflettere seriamente su quello che si dice intorno al database Mysql. Insomma, mi ci sono dovuto scontrare. E la battaglia, come spesso succede in questo genere di cose, non lascia né vinti né vincitori. Ma andiamo per gradi.

L’antefatto

Stavo sviluppando un Message Handling system (MHS) per la gestione di messaggi Cross-Platform (vedi XMS) il quale altro non è che una evoluzione della verisone 1.0 che ha prestato onorato servizio per alcuni anni, fino al 2009, quando la mia azienda Nastalia srl. si è dovuta purtroppo arrendere al mercato degli SMS in caduta libera.

Ho quindi deciso di riprendere il progetto per arricchirlo di nuove e più adeguate funzionalità, assumendomi l’onere di riscrivere da zero gran parte del codice (al momento circa il 75% del codice è già stato riscritto) e soprattutto di renderlo compatibile per il tanto decantato database Mysql oltre che per Postgresql.

Sono stati quindi riscritti i driver di connessione al database e tutte le primitive per l’utilizzo delle API opportune (MySql e Postgresql)

Durante la fase di studio del progetto e della stesura delle linee guida dei meccanismi di utilizzo del DB, mi sono subito accorto che mysql mi avrebbe creato non pochi problemi, costringendomi a rivedere l’intero impianto progettuale.

L’approccio iniziale era molto pulito (o almeno questa voleva essere l’idea), ovvero: il motore di messaggistica (XMS-Engine) doveva essere un puro switch di messaggi quasi completamente indipendente dal database. Ciò avrebbe richiesto pochissime API avrebbero permesso al “motore” di interagire con il DB (qualunque esso sia) e lasciare che tutte le operazioni sui dati venissero assolte dalla BI del database stesso. tale architettura avrebbe consentito di scaricare l’onere del “motore” di avere conoscenza dettagliata dei dati (nomi delle tabelle, delle colonne, etc.).

Se l’applicazione di questo meccanismo era stato estremamente semplice utilizzando il database Postgresql (alcuni test sono stati anche effettuati con successo con Oracle DB) la stessa cosa non si può dire per il database MySql.

Il Problema del database MySql

Fatta la doverosa premessa più sopra, per far meglio comprendere lo scenario, passiamo ad analizzare le problematiche incontrate con mysql.

1. Mysql non può usare ROWTYPE

In una Stored Procedure o in una Function esiste un modo estremamente semplice per poter utilizzare i dati provenienti da una query che ritorna un resultset senza preventivamente conoscere il data-type di ogni singola colonna: il datatype ROWTYPE.

Ovviamente è necessaria la dichiarazione iniziale, ma tutto il resto del codice diventa estremamente semplice, in quanto non è necessario dichiarare tutti i tipi di dati di tutte le colonne restituite d una query (pratica piuttosto lunga e tediosa, non immune da errori), è sufficiente dichiarare inizialmente la variabile di tipo ROWTYPE che conterrà tutte le colonne (incluso il loro Datatype) ed utilizzarla come una semplice variabile strutturata.

Vediamolo all’opera con un esempio in una Function di Postgresql.

 1 CREATE OR REPLACE FUNCTION AB.AB_CR_F_user_recharges(text, text, double precision, integer, integer)
  2     RETURNS bigint AS
  3 $BODY$
  4     DECLARE
  5     --  Calling arguments
  6     _c_id       ALIAS FOR $1;       -- Customer ID
  7     _b_id       ALIAS FOR $2;       -- Bill Rule ID
  8     _amount     ALIAS FOR $3;       -- Amount to recharge
  9     _type       ALIAS FOR $4;       -- Recharge type (one of RECHARGE_TYPES table).
 10     _method     ALIAS FOR $5;       -- Recharge method (one of RECHARGE_PAYMETHOD table).
 11 
 12     -- Context parameters
 13     _rec_rchpl  recharge_pricelist%ROWTYPE;  -- Record for table: recharge_pricelist
 14 
 15     -- [more code lines here] ...
 16 
 17     -- Get recharge_pricelist record for the given recharge amount...
 18     SELECT * 
        INTO _rec_rchpl 
        FROM PUBLIC.recharge_pricelist r 
        WHERE 
            r.rchpl_id = _amount 
        AND r.rchpl_cgroup = _rec_customer.c_group;
 19     IF _rec_rchpl.rchpl_id IS NULL THEN
 20         RAISE NOTICE 'Recharge Error. Recharge amount out of range !'; RETURN -1;
 21 
 22     -- [more code lines here] ...
 23 
 24 $BODY$ LANGUAGE 'plpgsql';

Nella riga 13 viene definita la variabile _rec_rchpl di tipo ROWTYPE, nella riga 18 la variabile viene caricata con il risultato della query, nella riga 19 viene utilizzata. In totale 3 righe di codice (error proof) per manipolare un intero record di dati.

In Mysql tutto ciò non è possibile; è necessario dichiarare tutte le colonne che si vogliono utilizzare ed eseguire una query specifica per le colonne da utilizzare. Se le colonne sono qualche decina, le righe di codice saranno moltissime di più, a tutto svantaggio della leggibilità della possibilità di errore e delle performance complessive.

Ma questo è solo uno dei problemi, tra quelli più fastidiosi, che ho incontrato; ce ne sono moltissimi altri. Qui di seguito un brevissimo elenco dei problemi di compatibilità con cui mi sono scontrato.

1. CREATE SCHEMA

Non è possibile creare schemi all’interno dello stesso database. In Mysql il database è un’area monolitica, senza possibilità di creare compartimenti stagni al suo interno, per l’aggregazione omogenea degli oggetti (tabelle, funzioni, ecc.). Questo meccanismo offre grandi vantaggi anche per quanto riguarda la sicurezza.

2. Database link

Mysql non sembra avere la possibilità di utilizzare i Database Link in modo trasparente all’applicazione.

3. SYNONYMS

Non c’è alcuna possibilità, con Mysql, di creare sinonimi di oggetti. A dire il vero, questa caratteristica non esiste neppure in Postgresql, ma tramite il meccanismo dell’Overloading, si possono ottenere risultati molto simili, in alcune circostanze.

4. User Defined Data Types

Al momento (Mysql versione 5.5.x) non vi è alcuna possibilità di utilizzare gli “User Defined Data Types”,. È quindi possibile esclusivamente utilizzare i tipi di tati predefiniti.

5. Function-Procedure resultset per “INSERT INTO…”

Mysql non è in grado di restituire un Result-Set per uno statement Sql INSERT INTO SET = . Questo costringe il programmatore ad “invertare” soluzioni alternative, a tutto svantaggio delle performances, della leggibilità del codice, dei tempi di sviluppo, ecc.

6. TRIGGER

I trigger sono qualcosa di veramente ostico da gestire in Mysql: non sono quello che si può chiamare “uno strumento flessibile”.

7. Cursors

In Mysql i cursori sono un vero incubo, oltre che molto inefficienti.

8. TRIGGERS ARE NOT PROCESSED FOR NOT NULL COLUMNS.

Effettivamente questo sembra essere un Bug (BUG#6295, Opened [27 Oct 2004 23:30] Peter Gulutzan, fixed in 5.7.1). Ma non è strano che un bug di questa importanza se ne stia seduto li, dimenticato da tutti dal 2004? Sembra che nella versione 5.7.1 sarà sistemato, mi sono riservato di fare un test su questa versione.

Con quanto detto fin’ora, è difficile comprendere il motivo di tanto clamore per Mysql. In realtà questo database, mette a disposizione pochissimi strumenti per la manipolazione dei dati e sembra avere ha un linguaggio di programmazione estremamente povero; di fatto inutile per sviluppare un “motore”di database efficiente ed autonomo. Mysql ha più che altro, tutta l’apparenza di più di un “file manager” evoluto piuttosto che di un database vero e proprio. Ma soprattutto che, preso da solo, serva a ben poco; ha bisogno di PHP per poter ottenere qualche funzionalità almeno decente (Vedi; LAMP).

Sicuramente è un database semplice da usare per chi ha poche pretese; non a caso da il meglio di se nelle applicazioni web, come supporto al PHP. Ma non gli chiederei di fare qualcosa di più, forse è nato proprio per questo tipo di applicazione e…. Va bene così. Ma non chiamiamolo “database”, per favore!.

ho trovato numerosi interessanti articoli in rete. Per i più curiosi e per chi vuole approfondire, quello che segue è un breve elenco di siti che approfondiscono, meglio di me, l’argomento. Alcuni sono in inglese, mentre altri sono un po vecchi (si riferiscono a vecchie versioni), ma sono comunque interessati per comprendere meglio le differenze.

Riferimenti

• http://www.postgresqltutorial.com/postgresql-vs-mysql/
• http://www.quora.com/What-are-pros-and-cons-of-PostgreSQL-and-MySQL

Buona lettura e buon divertimento

Condividi