La nostra soluzione è indipendente dal database, quindi possiamo usarla con qualunque DBMS preferiate.
Quante volte ho sentito questa frase pronunciata da un qualche vendor di soluzioni informatiche!
Quello che si nasconde dietro questa frase è l'illusione della portabilità, ovvero il poter riusare la soluzione informatica in contesti disparati e con DBMS differenti.
Certo, la portabilità è buona, ma va saputa usare nel modo piu' opportuno, e farsi vanto di essere indipendenti dal database non sempre è una buona cosa, anzi per me è un errore grosso e anche grossolano.
E' un errore grosso perché generalmente al cliente finale non interessa l'interoperabilità del sistema proposto con altri DBMS. Lo scopo del cliente è quello di avere una soluzione informatica funzionante e performante (quest'ultimo punto è spesso molto importante), mentre l'indipendenza dal database è un fattore di interesse generalmente per gli sviluppatori. E' pur vero che il cliente potrebbe avere già un suo DBMS installato (o preferito) sul quale vuole far girare la applicazione in questione, e quindi avere un modo per "convertire" l'applicazione ad un altro DBMS è una buona cosa. Ma la parola chiave, spesso ignorata, è appunto "conversione": un conto è avere una soluzione informatica portabile, ovvero convertibile facilmente ad un'altra architettura (ossia ad un altro DBMS) e un conto è avere un sistema che è svincolato dal tipo di DBMS e quindi è già pronta per qualunque architettura. Quest'ultima soluzione, a mio avviso, è la peggiore. I piu' staranno saltando sulla sedia vista questa mia affermazione. Per meglio capire il mio pensiero occorre valutare anche la seconda parte dell'errore circa l'indipendenza dal database: la grossolanità.
Reputo l'indipendenza dal database un errore grossolano poiché automaticamente significa escludere tutte le funzioni evolute che il DBMS puo' offrire, e che nella maggior parte dei casi sono vendor-specific. Il rifiuto di ogni cosa non assomiglia ad una query standard porta a due problemi principali:
Quello che si nasconde dietro questa frase è l'illusione della portabilità, ovvero il poter riusare la soluzione informatica in contesti disparati e con DBMS differenti.
Certo, la portabilità è buona, ma va saputa usare nel modo piu' opportuno, e farsi vanto di essere indipendenti dal database non sempre è una buona cosa, anzi per me è un errore grosso e anche grossolano.
E' un errore grosso perché generalmente al cliente finale non interessa l'interoperabilità del sistema proposto con altri DBMS. Lo scopo del cliente è quello di avere una soluzione informatica funzionante e performante (quest'ultimo punto è spesso molto importante), mentre l'indipendenza dal database è un fattore di interesse generalmente per gli sviluppatori. E' pur vero che il cliente potrebbe avere già un suo DBMS installato (o preferito) sul quale vuole far girare la applicazione in questione, e quindi avere un modo per "convertire" l'applicazione ad un altro DBMS è una buona cosa. Ma la parola chiave, spesso ignorata, è appunto "conversione": un conto è avere una soluzione informatica portabile, ovvero convertibile facilmente ad un'altra architettura (ossia ad un altro DBMS) e un conto è avere un sistema che è svincolato dal tipo di DBMS e quindi è già pronta per qualunque architettura. Quest'ultima soluzione, a mio avviso, è la peggiore. I piu' staranno saltando sulla sedia vista questa mia affermazione. Per meglio capire il mio pensiero occorre valutare anche la seconda parte dell'errore circa l'indipendenza dal database: la grossolanità.
Reputo l'indipendenza dal database un errore grossolano poiché automaticamente significa escludere tutte le funzioni evolute che il DBMS puo' offrire, e che nella maggior parte dei casi sono vendor-specific. Il rifiuto di ogni cosa non assomiglia ad una query standard porta a due problemi principali:
- si reinventa la ruota;
- non si sfrutta al massimo il DBMS.
Il primo problema è facile da capire: il DBMS ha come solo scopo la gestione dei dati, e lo fa al meglio delle proprie capacità. Se non ci si fida del DBMS e si vuole riprogettare tutto quello che potrebbe essere fatto con estensioni del DBMS stesso (ad esempio query complesse via stored procedure) allora si sta scrivendo codice per replicare le funzionalità del DBMS. Questo risulta in uno spreco di risorse, tempo e generalmente in performance cattive. Unitamente a questo si ha che non si sfrutta il database al 100%, e considerando che spesso ci si trova a pagare licenze (dal costo elevato) per il solo utilizzo del DBMS, ciò corrisponde ad una perdita economica non sempre trascurabile. In altre parole, spesso il cliente si trova a pagare un costo di licenza per uno strumento, il DBMS, che viene usato solo in parte, e paga contemporaneamente i costi della realizzazione del software che implementa quelle funzionalità che non vengono sfruttate nel DBMS stesso!
A questo punto, dovrebbe iniziare ad essere chiaro che l'indipendenza dal database non sempre è una buona cosa, almeno per il fatto che implica costi aggiuntivi sul cliente (e sul fornitore prima).
Quindi non si deve progettare il sistema in modo che sia portabile? Ovviamente no, occorre fare una scelta implementativa mirata (ovvero stabilire quale DBMS puo' fornire il miglior rapporto qualità/prezzo per il sistema) e fornire implementazioni di supporto per i DBMS che non offrono le funzionalità richieste. In sostanza, occorre legarsi ad un DBMS e cercare di fornire supporto per gli altri, ma occorre che lo sviluppo sia orientato ad un DBMS specifico! Dopotutto scelte del genere nel processo di sviluppo sono già state fatte: la scelta del linguaggio, la scelta dell'IDE, la scelta del framework MVC, ecc., allora perché il database non dovrebbe sottostare a scelte analoghe?
L'indipendenza da un componente importante come il DBMS è per me utopia; è come se si comprasse un paio di scarpe ma non si usassero i lacci, perché dopotutto non tutte le scarpe hanno i lacci e quindi non si vogliono prendere abitudini non portabili. Ma così non si riuscirà mai a correre bene! E lo stesso avviene con i DBMS, che se non vengono sfruttati non possono fornire prestazioni elevate.
Quindi occorre fare una scelta, spesso coraggiosa: legarsi ad un DBMS che offra le migliori feature per il progetto che si sta facendo. E se il database è libero, allora questa scelta non imporrà costi addizionali sul cliente e potrà essere accettata facilmente.
A questo punto, dovrebbe iniziare ad essere chiaro che l'indipendenza dal database non sempre è una buona cosa, almeno per il fatto che implica costi aggiuntivi sul cliente (e sul fornitore prima).
Quindi non si deve progettare il sistema in modo che sia portabile? Ovviamente no, occorre fare una scelta implementativa mirata (ovvero stabilire quale DBMS puo' fornire il miglior rapporto qualità/prezzo per il sistema) e fornire implementazioni di supporto per i DBMS che non offrono le funzionalità richieste. In sostanza, occorre legarsi ad un DBMS e cercare di fornire supporto per gli altri, ma occorre che lo sviluppo sia orientato ad un DBMS specifico! Dopotutto scelte del genere nel processo di sviluppo sono già state fatte: la scelta del linguaggio, la scelta dell'IDE, la scelta del framework MVC, ecc., allora perché il database non dovrebbe sottostare a scelte analoghe?
L'indipendenza da un componente importante come il DBMS è per me utopia; è come se si comprasse un paio di scarpe ma non si usassero i lacci, perché dopotutto non tutte le scarpe hanno i lacci e quindi non si vogliono prendere abitudini non portabili. Ma così non si riuscirà mai a correre bene! E lo stesso avviene con i DBMS, che se non vengono sfruttati non possono fornire prestazioni elevate.
Quindi occorre fare una scelta, spesso coraggiosa: legarsi ad un DBMS che offra le migliori feature per il progetto che si sta facendo. E se il database è libero, allora questa scelta non imporrà costi addizionali sul cliente e potrà essere accettata facilmente.
Nessun commento:
Posta un commento