Linee guida per un CMS casalingo: il database

Dopo aver trattato in linea generale la parte relativa al progetto del nostro CMS casalingo, ci occuperemo questa volta della questione riguardante il database.

Anche in questo caso voglio sottolineare che nulla di quello che espongo deve essere interpretato come regola tassativa, le esigenze che occorrono durante la creazione di un'applicazione possono essere tante e differenti, parliamo soltanto di linee guida basate sull'esperienza lavorativa personale e nulla di più.

A proposito di database, abbiamo già  sottolineato come sia consigliabile scegliere una soluzione basata su un DBMS, scartando l'ipotesi di un file di testo per la mancanza di una struttura relazionale e di un linguaggio appositamente dedicato alle relazioni tra i dati; MySQL non è necessariamente migliore, vi sono ottime soluzioni alternative (ad es.: PostgreSQL), ma per questo database engine è molto più semplice trovare supporto e risorse.

Ora passiamo alle caratteristiche del nostro database, in questo caso è possibile elencare alcune linee guida che spero possano essere utili:

• fate largo uso di tipi di dato ENUM, permettete cioè l'attivazione e la disattivazione di quanti più servizi e funzioni possibili. Un semplice campo che accetti come valori "0" e "1" risolve tanti problemi, rende l'applicazione adattabile a diverse esigenze e consente di non dover mettere mano al codice quando il cliente è del tipo "prima lo voglio e poi non lo voglio più";
• cercate di limitare al minimo indispensabile la ridondanza dei dati ma non fatevi prendere dall'ossessione del benchmark, se vi serve ripetere qualche informazione in più tabelle fatelo: meglio un millesimale calo delle performance che stare a scervellarsi dietro query, annidamenti, JOIN e raggruppamenti che non finiscono più;
• datate tutto, articoli, commenti, attivazioni etc.; la tentazione di ordinare i record per "id DESC" è molta ma, in un'applicazione in cui la pubblicazione dei contenuti può essere soggetta a moderazione e revisione, sono le date il punto di riferimento principale;
• sempre a proposito di date, se è possibile utilizzate tre campi differenti per inserimento, modifica e attivazione; anche in questo caso vi leverete di torno un sacco di problemi, in particolare telefonate tipo "l'ho scritto il mese scorso ma voglio che venga pubblicato con la data di oggi...";
• permettete la creazione di sotto-categorie illimitate: ai clienti le categorie non bastano mai.

L'ultimo punto è di particolare importanza, credo quindi che dedicherà un post apposito a questo aspetto. La struttura gerarchica dei contenuti è fondamentale nella concezione di un'applicazione in cui vogliamo mettere le mani il meno possibile.