Tempo fa feci notare a un programmatore freelance, che avrei preferito che sviluppassimo il database usando chiavi esterne con campi singoli interi, perché erano più comodi.
Il tipo trasalì. Diventò tutto rosso e mi rispose che TUTTI USANO LE CHIAVI MULTIPLE.
Sbagliando, lo lasciai fare.
Tempo fa si usavano le chiavi multiple, perché c'era scritto sul libro, perché lo spazio sui dischi era costoso e si risparmiava un campo in più, oppure il db non offriva le sequenze o contatori, quasi indispensabili quando si usa una chiave singola, oppure per motivi di fede in qualcosa che avevano sempre visto fare.
Onestamente, quando si affrontano problemi come la sincronizzazione dei dati su altre macchine, l'approccio tradizionale ha i suoi vantaggi e le sequence/campi contatore/campi identità diventano un problema.
In quell'applicazione le chiavi multiple erano soltanto una complicazione inutile.
Quel collega si sentiva protetto dalle abitudini. Da ciò che aveva sempre visto fare. Era insomma diventato schiavo della sua insicurezza, che placava ricorrendo alle stesse soluzioni.
In un'altra occasione mi trovai a discutere con due programmatori esperti, uno sosteneva che Hibernate fosse la soluzione ai tempi di sviluppo troppo alti che avevano afflitto il loro progetto, l'altro guardava sospirando la semplicità delle procedure Oracle. E' la vecchia diatriba tra se sia meglio tenere la logica nel middleware a oggetti o nelle stored procedure. Non ho mai sentito loro pronunciare le parole"dipende dal problema che si vuole risolvere".
I due erano degli eccellenti tecnici, ma avevano perso di vista che quello che facciamo è risolvere problemi. Fare progetti usando una tecnica sola e imporre quella come se fosse la via illuminata verso il successo è come pretendere di smontare un'automobile usando una sola chiave inglese.
Anche se in teoria forse è fattibile, qualsiasi meccanico si metterebbe a ridere di fronte a una simile proposta e probabilmente prenderebbe per matto chi si accapigliasse per sostenere questa tesi.
Per quanto mi riguarda, posso dire che io mi trovo molto più a mio agio a usare gli oggetti nel middleware, posto che questo non comporti la generazione inutile di migliaia di oggetti in memoria, però spesso ho risolto problemi di performance sfruttando il database, visto che spesso oggi le soluzioni dentro al database sono fatte in linguaggi portabili tra database diversi e sistemi operativi diversi.
Mi sembra un dato di fatto che il database debba essere sempre coerente e che quindi le regole di validità sui dati e l'integrità referenziale debba esserci, anche quando si usa prevalentemente il middleware, questo perché in futuro altre applicazioni potrebbero accedere al db e non vedrei il senso di moltiplicare le regole, replicandole nei vari strati.
Capisco meno magari chi si rifiuta di fare una semplice query dinamica per paura che sia lenta, dal momento che la preparazione del piano di esecuzione oggi spesso è in cache.
Io personalmente la vedo così: le query dinamiche hanno senso in contesti dinamici, quindi quando la query si costruisce dinamicamente cambiando volta per volta quali campi o filtri sono coinvolti. Credo che rinnegare un database relazionale maturo e magari costoso non abbia senso, in quanto non ha senso spendere fino al punto di rischiare un fallimento per risolvere problemi che non si hanno. Questo può sembrare un controsenso perché a tutti viene insegnato di prepararsi (per non dire addirittura preoccuparsi, altro errore) per il futuro.
Eppure viviamo nel presente. Sembra strano ma roviniamo il presente che è certo per il futuro che è incerto.
Io stesso ho fatto procedure enormi con strati che ripetevano le stesse cose per ciascun strato: un controllo javascript sulla pagina html, poi lo stesso controllo nel middleware, poi altri controlli nel db. Questo si traduce in COSTO. Un costo per una qualità non sempre richiesta.
Credo che non tutte le applicazioni abbiano bisogno di essere strutturate come il sistema informativo di una banca, così come non tutte le persone sono disponibili a pagare auto di lusso pluriaccessoriate e sono felici di usare delle utilitarie a un costo che è una frazione. Questo non vuol dire non fare lavori di qualità, vuol dire fare lavori nei costi che chi paga è disponibile ad accettare.
Chi non capisce questo e segue la strada maestra indicata nei forum e nei libri, per sentirsi sicuro di avere fatto il lavoro a regola d'arte e tutelarsi dalle critiche future dei colleghi, dalle contestazioni dei clienti e dalle future richieste di modifiche stravolgenti, è soltanto un insicuro, perché la gente è libera di criticare in base al pensiero del momento, perché il cliente si accorge di cosa vuole quando in effetti mette le mani sulla programma, perché cosa ci accadrà è stimabile, ma imprevedibile. E' la vita.
Nessun commento:
Posta un commento