Categoria: Programmazione

Tra le cose che più destano indignazione nel mio lavoro, è quello di vedere colleghi o sedicenti tali, fare un uso delle tecnologie in modo errato, non avendo a cuore la lungimiranza e gli eventuali problemi che potrebbero verificarsi da li a poco.
Tra tutte le regole che ho imparato in 10 anni di lavoro ed altrettanti di studio è che prevenire è meglio che curare, e che con gli attrezzi giusti sei già a metà dell’opera.

Oggi voglio parlare di tutti quei web developer, che per scelta o causa di forza maggiore decidono di occuparsi anche della progettazione della base di dati su cui poi andrà a girare l’applicazione web scritta con un linguaggio server side, (PHP, Ruby, Python, ASP, ecc.)

Quello che trovo nella maggior parte dei casi quando non c’è un DBE (Database Engineer) a svolgere il delicato ruolo di progettare la base di dati, è  un progetto inconsistente, non performante e lacunoso sotto tutti i punti di vista.

Ciò potrebbe anche “andar bene” qualora gli effetti nefasti di una cattiva progettazione non mettano a rischio l’integrità dei dati e la coerenza del database stesso, o nei casi in cui l’integrità dei dati e la coerenza non siano uno dei requisiti fondamentali da tener presente in fase di progettazione.

Vuoi perchè sia un blogghettino personale, vuoi perchè i dati trattati non hanno un valore tale da giustificare un’accurata pianificazione e progettazione dello stesso.

Non è invece possibile vedere progetti campati per aria quando si ha a che fare con software seri che gestiscono informazioni riservate o dati fiscali e finanziari, in cui l’integrità e la consistenza della base di dati è fondamentale.

Anche un “banale” e-commerce dovrebbe rispondere a questi requisiti.

La realtà è fatta invece di dilettanti che usano i potentissimi RDBMS, (normalmente in ambito LAMP MySQL) limitandosi all’utilizzo più banale che se ne possa fare : un semplice “archivio con tanti cassetti” in cui fare INSERT, SELECT, UPDATE, e DELETE tramite l’applicazione web che ci gira sopra.

Funzionalità come Viste, Stored Procedure, integrità referenziale, Trigger, Transazioni, Indici , vengono prettamente ignorate.

Se una persona competente decidesse di eliminare la casa automobilistica FIAT dal database veicoli a cui è referenziata la tabella modelli:

FIAT

– Panda
– Punto
– Palio
– Siena
– Brava

Avrebbe solo l’accortezza in fase di progettazione di settare il vincolo ON DELETE CASCADE, sulla relazione Casa<-Modelli.
Questo vincolo impartisce l’ordine di cancellare i record referenziati alla cancellazione della chiave primaria esterna a cui è stata referenziata.

Un dilettante invece dovrebbe scorrere tutta la tabella modelli, cancellare tutti gli elementi con una DELETE FROM Modelli WHERE casa like “FIAT”; e solo successivamente salire al “nodo padre” e cancellare definiticamente la casa automobilistica con un DELETE FROM Casa WHERE nomecasa LIKE “FIAT”;

Cosa succede poi quando un DB genera un errore ?

Vuoi che sia generato a livello applicativo da un codice scritto male, vuoi che vada via l’energia elettrica, la rete, o si rompa l’alimentatore ?

Mettiamo l’ipotesi banale in cui due utenti della stessa banca, decidano di farsi un bonifico tra loro : Tizio bonifica 1000 euro a Caio.

Tizio fa click col mouse, il sistema riceve il dato, toglie 1000 euro a Tizio e … BUM (scoppia l’alimentatore del server).

Arriva il tecnico, ripara l’alimentatore, riavvia il sistema e ci troviamo nella condizione in cui Tizio ha 1000 euro in meno sul suo conto, Caio non ha 1000 euro in più, in quanto l’operazione di accredito non è andata a buon fine perchè appena prima l’alimentatore si è rotto.

In queste situazioni un progettista serio avrebbe dovuto usare una TRANSAZIONE ACID, ovvero una metodologia per eseguire un gruppo di query, in cui o le si eseguono TUTTE, o si ripristina il DB allo stato iniziale, prima dell’esecuzione del gruppo di query.

Nel caso avesse usato una transazione, al riavvio del sistema, il DBMS avrebbe letto i log e accorgendosi che era stata eseguita solo una parte delle query, avrebbe eseguito il ROLLBACK e ritornato nelle condizioni iniziali prima del bonifico.

Questi esempi sono volutamente banali in quanto rivolti appunto a coloro che approcciano al mondo dei DB, senza avere padronanza di concetti basilari come modello E/R, normalizzazione e peculiarità di DBMS Relazionali avanzati come possono essere MySQL, PostgreSQL, Oracle, SQL Server o altri.

La pigrizia spesso genera quella falsa illusione di fare bene le cose, ignorando funzionalità che permettono di farle in maniera molto più facile e sopratutto sicura.

Approcciare ad una sana lettura sulle potenzialità del motore InnoDB, e le relative differenze con MyISAM, per chi si approccia alla progettazione di una base di dati su MySQL è il primo passo.