Home
Database * altezza / 2

02 Febbraio 2015

Database * altezza / 2

di

Spesso scegliamo un CMS solo perché lo conosciamo bene. Spesso, dovremmo sceglierlo sulla base del DB sottostante.

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.

L'autore

  • Luca Accomazzi
    Luca Accomazzi (@misterakko) lavora con i personal Apple dal 1980. Autore di oltre venti libri, innumerevoli articoli di divulgazione, decine di siti web e due pacchetti software, Accomazzi vanta (in ordine sparso) una laurea in informatica, una moglie, una figlia, una società che sviluppa tecnologie per siti Internet

Iscriviti alla newsletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.