Giu la maschera, mySql !

Giù la maschera MySql. Mostra chi sei veramente!

Qualche tempo fa mi stavo chiedendo se il grande clamore intorno al database Mysql fosse qualcosa di concreto oppure soltanto un gran polverone. Ho avuto la necessità di sviluppare un'applicazione ed avevo la necessità di utilizzare uno strumento per lo store dei dati strutturati, per cui il mio primo pensiero è andato a Mysql. Semplice da usare, gratuito, grande quantità di forum e documentazione in rete... Ma sono subito cominciati ad emergere alcuni importanti problemi che mi hanno costretto a riflettere seriamente su quello che si dice intorno a 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.

Sto 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 mometo 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 DB 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, ovvero, pochissime API che permettevano 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, scaricando così l'onere del "motore" di avere conoscenza dettagliata dei dati (nomi delle tabelle, delle colonne, etc.) Se l'applicazione di questo meccanismo è stato estremamente semplice utilizzando il database Postgresql (alcuni test sono stati anche effettuati con successo con Oracle DB) la stessa cosa non è applicabile per mil database mysql.

Fatta questa doverosa premessa, per farti 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 (ed il loro Data-Type) 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 volgiono 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 legibilità 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 <table> SET <column> = <value>. 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.

Buona lettura e buon divertimento

 

1 commento

  • Mark

    inviato da Mark

    Mercoledì, 25 Maggio 2016 20:58

    Convengo sul fatto che MySql non è maturo, ma il fatto triste è che postgresql non è fornito da alcun provider di webhosting.

Lascia un commento

Tutti i commenti dovranno essere verificati ed approvati dal webmaster, prima di essere pubblicati

 

Quote of the Day

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.

Albert Einstein

Chi è online

Abbiamo 316 visitatori e nessun utente online

Newsletter

Per essere sempre aggiornato sulle ultime novità.

Go to top