Postato il 24 Settembre 2012 da Paolo Predonzani

Oggi si dà per scontato che un CMS debba avere un database sottostante, specialmente nel mondo Java. In questo articolo vediamo le motivazioni che portano alla scelta del database ma anche gli svantaggi che ne derivano. Analizziamo anche un approccio alternativo basato su file system.

Ok mettiamo tutto sul database

Cosa va su database e cosa su file system sono scelte progettuali. La maggior parte dei CMS, ad esclusione dei file di configurazione, mette su database qualunque dato: le pagine, gli articoli, i commenti, altri contenuti e gli utenti. Questa centralità del database è dovuta al fatto di voler sfruttare i vantaggi dei db relazionali quali la gestione della concorrenza e la possibilità di fare interrogazioni in modo semplice.

Consideriamo la concorrenza. E’ proprio necessaria? In certi casi sì in certi casi no. La struttura delle pagine di un sito spesso cambia molto lentamente. Non ci riferiamo al contenuto, ma piuttosto all’organizzazione gerarchica delle pagine. Questo è vero non solo per siti di piccole dimensioni ma anche per portali di diverse centinaia di pagine. La ristrutturazione di un sito è un’attività pensata a tavolino e poco soggetta a concorrenza.

Anche per siti che gestiscono migliaia di articoli, p.e. i giornali on-line, la struttura delle pagine è piuttosto fissa. Homepage, sotto-siti e sezioni sono relativamente stabili e anche le pagine che visualizzano la moltitudine degli articoli hanno uno schema prefissato.

E’ invece vero che i commenti agli articoli hanno una frequenza di cambiamento molto elevata e che il dato può essere gestito bene da database.

Da qui emergono varie velocità di cambiamento. Per riassumere ed esemplificare: 

  • La struttura delle pagine cambia molto di rado
  • Gli articoli cambiano abbastanza frequentemente
  • I commenti cambiano spesso

Possiamo trovare una correlazione fra questi tipi di dato e le persone che se ne occupano. La struttura delle pagine è di competenza degli sviluppatori del sito (categoria in cui possono rientrare anche progettisti e redattori di alto livello). Gli altri due (articoli e commenti) sono di competenza degli utenti. Mentre per gli utenti avere i dati su database può essere comodo, il fatto di avere le parti di competenza degli sviluppatori su db merita ulteriore analisi.

Incubi da versionamento su database

Sarà capitato a tutti di creare una nuova versione del sito in sviluppo e di doverla applicare in produzione. In sviluppo abbiamo qualche cambiamento strutturale delle pagine. In produzione abbiamo qualche articolo nuovo e una marea di commenti nuovi. Bisogna applicare selettivamente soltanto le modifiche strutturali. Trovandosi tutto su database, dobbiamo individuare le righe interessanti in sviluppo e copiarle in produzione.

Consideriamo un altro caso. Due o più sviluppatori lavorano su sezioni distinte del sito. Ogni sviluppatore in locale ha un database. Quando occorrerà andare in produzione, bisognerà effettuare il merge di più database, risolvendo eventuali conflitti in modo manuale e ad hoc di volta in volta.

Come variante del precedente caso, ci possono essere modifiche di struttura del sito applicate direttamente in produzione. Queste devono essere riportate agli ambienti di sviluppo.

Infine consideriamo il caso in cui una versione già pubblicata in produzione non funzioni e sia necessario tornare alla versione precedente. Potremmo ripristinare tutto il db da un dump ma perderemmo i commenti pubblicati nel frattempo, oppure potremmo rimuovere solo le righe problematiche. In ogni caso si tratta di un lavoro manuale e soggetto a errore umano.

E’ vero che alcuni CMS sono consci di queste problematiche e offrono strumenti per lo stanging, la propagazione dei cambiamenti e l’import/export parziale delle pagine. Si tratta però di strumenti specifici di ciascun CMS. Mancano di generalità e non necessariamente risolvono tutti i casi che abbiamo parlato.

Gioie da versionamento su file system

Tutte le problematiche esposte sarebbero immediatamente risolvibili se la struttura delle pagine fosse su file system. Abbiamo a disposizione strumenti di version control molto ben collaudati e conosciuti: cvs, svn, mercurial, git, bazaar sono solo alcuni esempi in ambito open source.

Consideriamo cosa vuol dire applicare delle modifiche fatte in sviluppo al sistema in produzione. Vuol dire lanciare un comando sul VCS e ritrovarsi i file corrispondenti alla versione desiderata. Semplice!

Consideriamo i due o più sviluppatori che lavorano in parallelo. Se il CMS è ben modularizzato, sezioni diverse del sito corrispondono a cartelle e file diversi. Gli sviluppatori possono lavorare senza interferire.

Consideriamo il caso in cui una versione già pubblicata in produzione non funzioni. Tornare ad una versione precedente è di nuovo una funzione standard dei VCS. E’ vero che ogni tanto ci saranno situazioni di conflitto. A volte gli sviluppatori potranno toccare qualche file xml in comune. Si tratta comunque di un problema che sappiamo risolvere e il quale abbiamo strumenti adeguati indipendenti dal CMS utilizzato.

Infine i VCS offrono funzioni quali tagging o branching che permettono di organizzare meglio il lavoro.

Conclusioni

In questo articolo siamo partiti osservando che i database offrono vantaggi per quanto riguarda la gestione della concorrenza. Abbiamo però rilevato che per dati che cambiano poco e sono di competenza degli sviluppatori il database è più un impedimento che un vantaggio.

D’altro canto un CMS che si appoggia al file system per la struttura delle pagine è un vantaggio proprio nella gestione dell’accesso concorrente fra sviluppatori.

Questo secondo approccio è quello che utilizziamo in Portofino dove delle directory, dei file xml e altre risorse su file system definiscono la struttura del sito. Il file system porta altri vantaggi, oltre a quello del versionamento, che qui non abbiamo approfondito ma che vedremo in altri articoli.

 

comments powered by Disqus