La maggior parte dei sistemi di gestione dei contenuti open source utilizza un database per archiviare i dati del campo e quindi utilizza i file nella directory del server per le impostazioni di configurazione. Perché questo modello viene scelto così spesso e perché non sarebbe altrettanto efficace mantenere un file sul server per memorizzare i dati del campo? Questo cambierebbe se l'obiettivo fosse un sito grande e professionale con molti dati?
Il filesystem è un database, in particolare una sorta di archivio di valori chiave gerarchici con un po 'di metadati aggiunti, a seconda del file system.
L'uso di un filesystem è spesso appropriato, specialmente per i record di grandi dimensioni. (I filesystem hanno spesso una dimensione minima del record dell'ordine dei kilobyte). Se usati correttamente, i filesystem hanno un'atomicità e una durabilità simili a quelle di un database. In particolare, sia i database che i file system di journaling utilizzano la registrazione write-ahead.
Ma rispetto ad altri database, i filesystem hanno quattro gravi limitazioni:
Un file system non può essere condiviso tra più server. Ma più server possono connettersi a un singolo server di database.
In un filesystem, i file sono solo indicizzati dal loro percorso. Non è possibile aggiungere indici secondari, a meno che non si aggiunga un altro percorso che è un collegamento software alla chiave primaria o un collegamento reale al contenuto. Quando modifichi un file, devi aggiornare manualmente questi indici.
Mentre le operazioni su singoli file possono essere eseguite atomicamente, non è possibile creare transazioni che coinvolgono più file. La soluzione normale consiste nell'avere un file di blocco. Quando un processo ottiene un blocco su questo file, hanno accesso esclusivo in lettura e scrittura. Si noti che durante il blocco i file potrebbero trovarsi in uno stato incoerente, quindi non dovrebbero verificarsi altre letture. Quando il processo si blocca, potrebbe lasciare il file system in uno stato incoerente. Al contrario, RDBMS dispone di transazioni appropriate che possono eseguire il rollback delle modifiche in caso di errore e può consentire la lettura dello stato pre-transazione per altri client.
Il file system non ha mezzi per assicurare la coerenza dei dati. Ad esempio, i vincoli di chiave esterna sono completamente impossibili. Ciò rende molto più difficile modellare i dati e molto più difficile scrivere applicazioni corrette che leggono e scrivono tali dati.
Una limitazione meno severa è che i file system possono essere più lenti dei database. Ma questo dipende molto dal caso d'uso e dal file system. Per esempio. i vecchi file system come ext2 hanno prestazioni notevolmente degradate quando una directory contiene troppe voci.
Alcune applicazioni si adattano bene all'utilizzo del file system come database. Ad esempio, Git lo fa abbastanza efficacemente ma ha anche un certo numero di proprietà uniche, come l'uso di record immutabili.
Per la maggior parte delle applicazioni, è preferibile un RDBMS: ottieni molte garanzie (ad es. durata e coerenza) quasi gratuite, senza doverle implementare nella tua applicazione. Puoi modellare relazioni nei tuoi dati, non solo una mappatura dei valori-chiave. Naturalmente queste funzionalità hanno un costo, ma il costo è impercettibile per la maggior parte delle applicazioni.
Quindi quando ci sono più processi, è preferibile un server RDBMS.
Se hai solo un singolo processo, potresti comunque gradire le garanzie di coerenza di un RDBMS. Ma invece di utilizzare un server separato, è possibile utilizzare un motore di database incorporato come SQLite. Questo può essere molto più veloce di un server di database poiché le tue query non vengono trasmesse su una rete. E può essere più veloce dell'utilizzo del file system: anziché aprire più file per ciascun accesso ai dati, il motore di database salta semplicemente in un singolo file.
La maggior parte dei CMS sono implementati in PHP. Il modello di richiesta PHP (processi di breve durata e molti processi possono essere eseguiti in parallelo) non si presta a database incorporati come SQLite e pertanto rende difficile l'uso corretto del file system come semplice DB. Invece, sono preferibili server di database esterni come MariaDB o PostgreSQL.
Se un sistema memorizza i suoi dati in un database, non è necessario memorizzare anche la configurazione in un database. In genere la configurazione viene letta una volta all'avvio e non viene modificata dall'applicazione. I dati di configurazione inoltre hanno in genere poche relazioni, rispetto ai concetti di dominio problematico di un CMS, ad es. le relazioni tra post, tag, utenti, diritti di accesso, ....
Ci sono molte cose che devono essere prese in considerazione. Un esempio è che le letture e le scritture del file system sono generalmente (relativamente) lente. I database tendono a mantenere una grande porzione dei loro dati nella RAM a cui si accede molto più velocemente. I database tendono anche a migliorare le piccole modifiche (ad esempio se si dispone di un file INI con impostazioni e necessario modificare una singola impostazione, rispetto a un database in cui è necessario modificare un singolo campo in una singola riga). Anche le singole modifiche in un database tendono a non richiedere alcun tipo di blocco come un file quando si scrivono le modifiche (anche se potrebbe essere necessario utilizzare le transazioni oi blocchi nei database in una varietà di circostanze, di solito sono ancora più efficienti).
Nota che, mentre più raro, ci sono momenti in cui un file di impostazioni ha più senso.
Leggi altre domande sui tag design web-development data-structures