Database * altezza / 2

Negli anni Novanta, quando cominciai il mestiere del webmaster, notai che il primo e più grande sitificio italiano (si chiamava Matrix, venne poi comprato da SEAT) realizzava tutti i suoi siti su una piattaforma chiamata Broadvision. Chiesi a uno dei fondatori, Carlo Panzalis, se fosse davvero così potente da poterci fare di tutto. Mi rispose di no, più semplicemente era lo strumento che in azienda sapevano usare. Ovvero, fa dire Arthur Bloch a Bernard Baruch:

Quando tutto quel che possiedi è un martello, tutto ciò che vedi comincia a sembrarti un chiodo.

L’andazzo mi pare lo stesso venti anni più tardi. Ho già accennato al fatto che tra i CMS le convergenze sono poche e preziose, gli strafalcioni tanti. Il prezzo più caro da pagare quando si sbaglia lo strumento però, secondo me, non deriva dal CMS in sé, quanto dal database sottostante. Rischia di essere un prezzo salatissimo per quanti addirittura ignorano del tutto la problematica.

Il caso più famoso è quello di Facebook. Notoriamente, il più famoso dei siti social venne costruito con un CMS scritto in PHP e basato sul database MySQL, come molti. Sia il linguaggio che la base dati si sono dimostrati poi inappropriati per reggere il boom del sito di Zuckerberg, e gli ingegneri sono stati costretti a fare i salti mortali riscrivendo di sana pianta pezzi del linguaggio e pezzi del database. Con costi stratosferici che realtà più piccole non possono certo permettersi.

Non aiuta il fatto che lo sviluppo di MySQL sia stato severamente ristretto quando quel programma open source, numero due nel mondo, è stato comprato qualche anno fa da Oracle, numero uno nel mondo e decisamente a pagamento. Non si può dunque far troppo conto sul fatto che MySQL migliori significativamente di suo e i tentativi del suo papà Monty Widenius di reinventarlo non sono andati lontanissimo.

Lenti database crescono

Un fattore di cui si rende conto anche il webmaster più distratto è quanto male lavori il database quando il numero di dati cresce. Non c’è CMS che tenga, quando superate le centomila righe il sito comincia a sputacchiare. Bisogna allora analizzare come funziona il sottostante linguaggio SQL e operare astruse alchimie su cose che si chiamano chiavi primarie, join, forme normali. Si può fare, se il CMS permette di lavorare a questo livello basso (ma tutti i più semplici non lo permettono).

Personalmente, sono riuscito a progettare e far funzionare velocemente commerci elettronici con oltre dieci milioni di prodotti individuali. Sull’altare della velocità bisogna però fare più di un sacrificio, tra cui la possibilità di cambiare cavallo. Lo standard SQL è tormentato da mille dialetti e scambiare MySQL con un altro motore (Oracle incluso) è un lavorone. Da qui il mio calembour iniziale, forse sciocchino, ma vero: quando sale la richiesta di prestazioni si frazionano i gradi di libertà progettuale. Certo, c’è anche NoSQL. Bbono quello, come dicono a Roma. Ne riparleremo.