1. 9

Oggi vi propongo una domanda che trae spunto dalla mia esperienza universitaria e dalle discussioni nate qui su Gambe.ro.

In un articolo postato qui un po’ di tempo fa da @chobeat mi ricordo di aver letto che un grosso incremento alle prestazioni di un backend poteva essere dato spostando parte della computazione all’interno del database tramite funzioni e procedure in PL/SQL o similari.

Nei commenti sotto il link a PostgREST (postato sempre da @chobeat) invece si diceva che c’è chi considera stored procedures e funzioni da evitare come la peste, tra le altre cose per aggirare il vendor lock-in indotto dall’uso di un linguaggio specifico dipendente dal database usato.

Come ho già detto in innumerevoli commenti qui, per l’università sto seguendo un corso di Laboratorio di Basi di Dati in cui si usano gli strumenti di Oracle, PL/SQL compreso, per cui di stored procedures ne ho fin sopra i capelli. Il problema è che si usano procedure e package PL/SQL per fare tutto, compresa la generazione di HTML, e usando pattern di progettazione totalmente inesistenti che portano a fare le cose nel modo più sbagliato possibile.

Io mi pongo quindi da una prospettiva esterna: non avendo mai usato stored procedures in uno scenario di backend vero e proprio, mi piacerebbe sentire i racconti di qualcuno che ci si è trovato, come ha fatto e cosa consiglia agli altri.

  1.  

  2. 4

    Un paio di considerazioni personali:

    • Il lock-in e’ un problema, ma inevitabilmente nello sviluppo di applicazioni succede di usare funzioni sql che sono disponibili solo per un database per questioni di efficienza
    • Stored procedure non sono il male se sono sotto controllo con git e puoi gestirle come qualsiasi altro pezzo di codice. Se devi fare il deploy manuale allora rischi di avere un drift tra quello che pensi sia la tua applicazione e quello che e’.
    1. 4

      Nella mia azienda gran parte delle business logic sono in PL/SQL e ti posso assicurare che lavorarci e’ un delirio (e infatti stiamo migrando tutto). Rendono la vita dello sviluppatore estremamente piu’ complicata che con una normale code base separata dal database. Sviluppo, testing, CICD… e’ tutto piu’ difficile.

      Sono sicuro poi che ci siano casi in cui possano essere usate in maniera intelligente, magari appunto per una questione di prestazioni.

      1. 3

        Premessa: non ho mai incontrato stored procedures nel mondo reale.

        Nella mia percezione sono uno strumento da utilizzare solo in fase di maturità del software per ottenere prestazioni più elevante, nella stessa maniera in cui si reimplementerebbe in C o Fortran un modulo particolarmente critico.

        1. 3

          Su questo tema sono abbastanza talebano: le stored procedure sono da evitare come la peste. Per me rappresentano un antipattern architetturale.

          I problemi di performance non si risolvono spostando logica di business sul database. Costa meno scalare orizzontalmente o verticalmente il sistema piuttosto che fare una scelta che comporterà un costo maggiore in termini di manutenibilità e vendor lock-in, per non parlare di tutte le altre implicazioni in termini di sviluppo, architettura, rilasci, portabilità, ecc.

          1. [Commento rimosso dall'autore]

            1. 2

              spesso il collo di bottiglia è proprio il dbms

              scali verticalmente o orizzontalmente il dbms, ottimizzi le query, aggiungi qualche indice, utilizzi meccanismi di caching… tutto pur di non usare le stored procedure

          2. 2

            Prima di iniziare a lavorare dove sono ora, non le avevo mai viste nel mondo reale e le disprezzavo abbastanza. Ora ammetto di aver cambiato abbastanza idea. Capisco il timore del vendor lock-in, ma quante volte vi è capitato, con un’applicazione in produzione, di dire “buttiamo via il vecchio DBMS e installiamo tutto da zero con un altro”? Perché nella mia esperienza, una volta che hai messo su uno (o più) cluster con il DB, in produzione si usa quello.

            D’altra parte, mi hanno spesso reso il refactoring o la sostituzione di componenti molto più facile, perché le estrazioni e gli inserimenti più critici venivano lasciati al DBMS e, anche cambiando linguaggio, posso avere la certezza che continuassero a funzionare come prima.

            1. 2

              quante volte vi è capitato, con un’applicazione in produzione, di dire “buttiamo via il vecchio DBMS e installiamo tutto da zero con un altro”?

              Ma se metti le stored procedures ti chiudi questa opportunità a prescindere.

              Purtroppo il problema dei software vecchi non è tanto l’utilizzo di linguaggi o tecnologie vecchie, ma l’utilizzo di architetture rigide che non forniscono la flessibilità richiesta per una trasformazione.

              Quindi un conto è andare ad ottimizzare un’applicazione vecchia, un conto è disegnare l’architettura di un’applicazione nuova: per la seconda proprio non vedo nessun beneficio nell’introduzione delle stored procedures, vedo solo tanti aspetti negativi

              1. 2

                È comunque un’eventualità abbastanza rara. È molto più facile che si cambino altri elementi che non il DBMS, e in questo caso ho notato, almeno nella mia esperienza, che le stored procedures facilitano il lavoro, perché riducono la quantità di cose di cui si deve occupare direttamente l’applicazione. Non mi sembrano una panacea e hanno evidenti problemi, ma ci sono situazioni in cui rendono la vita più facile.