Riflettendo dai Database ai micro-progetti...

Pensiero nato da una conversazione via email con un professionista, una piccola riflessione personale sullo sviluppo applicativo, principalmente concentrato sull'argomento Database.

Il tutto potrebbe essere essere più o meno ricondotto alla domanda: "qual'è il Database migliore per fare qualcosa?". Prima di rispondere con un nome, varrebbe la pena di riflettere sul know-how a cui si ha accesso. La risposta alla domanda diverrebbe... "quello che si conosce meglio".

Nello scoprire che per un progetto individuale venisse usato Oracle come database server, sono stato abbastanza (ma mica poi così poco) solleticato dalla curiosità (stranamente). Quando ho chiesto come mai venisse usato quel database come backend per i dati, la risposta è stata decisamente chiara e - secondo la mia opinione - inattaccabile: "è il database su cui ho iniziato a studiare SQL, e mi ci trovo bene".

Ognuno ha le sue preferenze in materia di programmazione. Nel tempo si adotta una metodologia e dei piaceri nell'utilizzo di una soluzione software piuttosto che un'altra. Se devo essere sincero, trovo molto irritante (irrispettoso e poco etico) etichettare i prodotti come "scadenti" perchè non li si conosce. Io lavoro molto con MySQL (dalla 3.16, che successivamente è diventato di Oracle) e sto riprendendo a studiare DB2 di IBM - per interesse personale ed esercizio. Ma quando mi capita di mettere le mani su SQL Server 2005 di Microsoft la reazione non è quella di etichettarlo come "non idoneo" e buttare via tutto, bensì di approfondire la conoscenza del sistema per riuscire a farlo rendere al meglio. Parole chiave per la ricerca di informazioni come "performance tuning" diventano piuttosto utilizzate nel tempo. Devo anche ammettere di essere riuscito anche a imparare parecchio e "spremere" bene le sue performance nel corso del tempo.

Nella realizzazione di progetti di piccole dimensioni la preferenza del Database che meglio si conosce è secondo me la scelta piu' azzeccata. E finchè si sviluppa sul PC di "casa" o ufficio, tutto va bene. Quando si passa in produzione, in particolare negli ambienti web (come siti Internet) le cose cambiano un po', e il disegno del DB e la sua manutenzione diventano un'attività importante, con aspetti sistemistici da tenere in considerazione.

Il primo che mi viene in mente quando si fa un "go-live" del progetto. La piattaforma di appoggio che si sceglie, supporta il sistema RDBMS che abbiamo deciso di utilizzare per il progetto? Ci sono soluzioni di hosting di svariati generi e probabilmente si puo' trovare qualcosa che risponda alle nostre esigenze, tuttavia se cosi' non fosse (per esempio usando Oracle Express Edition) la scelta dovrebbe cadere su una soluzione di locazione di un server virtuale (o mantenere il progetto in casa, a seconda della connettivita' disponibile e del contratto sottoscritto). Il secondo aspetto da tenere in considerazione negli ambienti condivisi o in Cloud e' che il gestore del servizio mantiene monitorate le prestazioni dei sistemi ospitati per evitare che un'utenza approfitti della potenza di calcolo bloccando gli altri servizi ospitati. A questo punto, un DB opportunamente strutturato va anche mantenuto "snello" per riuscire ad offrire da un lato le performance che ci si aspetta, e dall'altro non si corra il rischio di incappare in un blocco del servizio da parte del gestore.

Per concludere questa piccola riflessione su un argomento che ho improntato sul Database, ma che in realta' e' applicabile a qualsiasi ambito (linguaggio di programmazione, sistema operativo, etc.) credo che un confronto con un amministratore di sistema possa portare alla luce un confronto molto costruttivo ed interessante per entrambe le parti, che porterebbe a sua volta alla creazione di codice piu' gestibile, prestante e sicuro. Naturalmente la questione vale anche al contrario.