La grande illusione dell’astrazione totale

Il traduttore che parla male tutte le lingue

Immaginate di andare in Giappone con un interprete che conosce solo l’italiano scolastico e il giapponese imparato da un libro di testo. Tecnicamente vi sta traducendo. Praticamente state perdendo ogni sfumatura, ogni modo di dire, ogni riferimento culturale. E quando dovete chiedere indicazioni per un ristorante specifico o discutere di un problema tecnico, il traduttore vi guarda spaesato e improvvisa qualcosa che potrebbe anche non avere senso.

Questo è esattamente ciò che fanno gli ORM (Object-Relational Mapping) tra il vostro codice e il database. Sono interpreti universali che promettono di parlare fluentemente sia la lingua degli oggetti che quella delle relazioni, ma finiscono per parlare male entrambe.

La promessa è seducente: scrivete codice orientato agli oggetti e magicamente si trasforma in perfette query SQL. Non dovete più sporcarvi le mani con quel linguaggio “arcaico” che è SQL. È tutto pulito, elegante, object-oriented. Finché non scoprite che il traduttore ha interpretato la vostra richiesta di un’insalata come un ordine di portate per venti persone.

Quando il controllo diventa un optional

Il vero problema degli ORM non è tecnico, è filosofico. Rappresentano il sogno dell’astrazione perfetta: nascondere completamente la complessità sottostante. Ma la complessità non sparisce mai. Si nasconde solo, come polvere sotto il tappeto.

Considerate cosa succede con un database che non avete progettato voi. Un sistema legacy di quindici anni fa, con chiavi composite, relazioni che attraversano database separati, stored procedure ottimizzate. L’ORM cerca disperatamente di mapparlo su oggetti.

Il risultato è un codice che sembra semplice in superficie ma nasconde una complessità mostruosa. Ogni accesso a una proprietà potrebbe scatenare query nascoste. Ogni relazione potrebbe caricare megabyte di dati inutili. E voi non avete idea di cosa stia succedendo sotto il cofano.

È come guidare con il parabrezza opaco, delegando tutto al pilota automatico e sperando che sappia cosa sta facendo.

Il database come cittadino di serie B

C’è un presupposto arrogante negli ORM: l’idea che il modello a oggetti sia superiore al modello relazionale. Che SQL sia una lingua barbara da cui proteggere i delicati sviluppatori moderni.

Ma i database relazionali esistono da decenni per ottime ragioni. Sono ottimizzati per operazioni complesse. Hanno costrutti potenti che non esistono nei linguaggi di programmazione. Hanno motori di ottimizzazione che sanno esattamente come eseguire query efficientemente.

Gli ORM dicono: “Ignora tutto questo. Fammi credere di lavorare con oggetti in memoria.” E il database deve fare contorsioni per assecondare questa finzione.

È come quei GPS che vi portano per la strada panoramica invece dell’autostrada. Tecnicamente arrivate a destinazione, ma avete perso due ore e consumato il doppio del carburante.

La favola del database intercambiabile

“Ma se un giorno volessimo cambiare database?” È l’argomento difensivo classico. Gli ORM promettono indipendenza: scrivete il codice una volta e passate da MySQL a PostgreSQL senza modifiche.

Nella pratica? È una favola. Nel frattempo, avete pagato il prezzo ogni giorno. Query meno efficienti, debugging difficile, performance degradate. Tutto per uno scenario ipotetico che probabilmente non si verificherà mai.

È come un’assicurazione costosa contro i meteoriti. Tecnicamente potrebbe succedere, ma intanto spendete migliaia di euro all’anno per un evento con probabilità praticamente zero.

Il serial killer silenzioso delle performance

Parliamo del problema N+1, la maledizione silenziosa che uccide le performance mentre voi non ve ne accorgete. Funziona così: chiedete all’ORM di darvi una lista di dieci utenti. Semplicissimo. Ma poi volete anche i loro ordini. L’ORM, nella sua infinita saggezza, fa una query per prendere i dieci utenti, e poi una query separata per ogni utente per prendere i suoi ordini.

Totale: undici query invece di una. Ora moltiplicate per cento utenti. Mille. Diecimila. Vedete dove stiamo andando?

Il bello è che questo succede completamente all’insaputa dello sviluppatore. Il codice sembra innocente. Non c’è nessun loop esplicito che esegue query. Ma sotto il cofano, l’ORM sta bombardando il database come se non ci fosse un domani.

Quando finalmente vi accorgete del problema, perché il sistema è diventato insopportabilmente lento, dovete iniziare a contaminare il vostro bellissimo codice object-oriented con istruzioni specifiche dell’ORM per forzare l’eager loading, il lazy loading, i join espliciti. In pratica, state riscrivendo SQL ma con una sintassi più contorta.

L’ibrido che nessuno vuole

E poi arriva il colpo di grazia: database moderni che supportano JSON nativamente. “Fantastico!” esclama il manager entusiasta. “Il meglio di entrambi i mondi!”

No. State creando un mostro.

Usare colonne JSON in un database relazionale è come mettere un motore diesel in un’auto elettrica. Tecnicamente funziona, ma perdete i vantaggi di entrambe le tecnologie. Normalizzazione? Sparita. Foreign key? Dimenticate. Integrità referenziale? Un ricordo del passato.

Quando iniziate a mettere modelli complessi in colonne JSON “per comodità”, state rinunciando ai benefici del relazionale mantenendo tutti i suoi svantaggi. E l’ORM che cerca di mappare tutto questo? Buona fortuna.

La memoria che esplode

Gli ORM caricano oggetti completi anche quando vi serve solo un campo. È come andare al supermercato per il latte e tornare con l’intero reparto latticini.

Sono esistiti sistemi che al login caricavano l’intero database in memoria. Non era un bug evidente. Era solo uno sviluppatore che pensava: “Sono pochi oggetti Java, li carico subito.” Il problema? Quegli oggetti avevano relazioni che puntavano ad altri oggetti, in una cascata che finiva per sincronizzare tutto.

L’ORM non vi dice “Attenzione, stai per caricare 50GB.” Vi permette di scrivere codice che sembra innocente ma ha conseguenze devastanti.

La soluzione è tornare alle origini?

La verità scomoda è che ogni sviluppatore conosce già SQL. Non è un linguaggio oscuro e arcano. È uno standard consolidato, potente, espressivo. Permette di fare cose che negli ORM richiedono contorsioni mentali.

Allora perché fingiamo che sia un problema? Perché astraiamo qualcosa che non ha bisogno di astrazione? È come decidere che camminare è troppo complicato e muoversi solo su tapis roulant.

Se lavorate con un database SQL, parlate SQL. Direttamente. Senza intermediari che rallentano tutto e vi tolgono il controllo. Scrivete le vostre query, ottimizzatele, capite esattamente cosa succede.

Gli ORM sono la soluzione perfetta a un problema che non esiste. Risolvono il disagio psicologico di sviluppatori che non vogliono “sporcarsi le mani” con SQL, al prezzo di creare problemi reali di performance, manutenibilità e controllo.

Quando finalmente vi arrendete e scrivete SQL nativo comunque, perché è l’unico modo per ottenere performance decenti, vi ritrovate con il peggio di entrambi i mondi: la complessità dell’ORM più la necessità di conoscere SQL comunque.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT