Vor einiger Zeit entspann sich eine kurze Diskussion zwischen Christian Aust und mir auf Twitter, die in einer Aussage von mir gipfelte, daß ich Content Management Systeme ohne Datenbank für nicht gut halte. Nun hat er ein Posting dazu geschrieben. Das möchte ich kurz beantworten.

• Keine Datenbank, somit keine Migration: Das ist so nicht richtig. Migrationen entstehen, wenn sich das Datenmodell ändert. Auch Content auf der Platte in Textdateien hat ein inhärentes Datenmodell. Wenn sich das ändert, muß man alle Dateien einzeln durchgehen und umbauen. Das halte ich für schwieriger. Zudem existieren für alle CMSse, die ich kenne, Updater, die sowas im Hintergrund für mich erledigen.
• Das Produktivsystem ist nicht dynamisch schreibbar: verstehe ich nicht ganz. Ist das Verzeichnis mit dem Content-Baum read-only? Wenn ich einen Hacker auf dem Rechner habe (durch eine OS Sicherheitslücke), dann ist das völlig egal. Wenn es sich um eine CMS Sicherheitslücke handelt, ist es auch egal, weil das Markdown der Contentdateien ja noch dynamisch durch das Ruby CMS müssen. Vielleicht verstehe ich das Argument auch einfach noch nicht.
• Dateiverwaltung geschieht über Dateitools und Versionsmanagement: WordPress ist ein denkbar schlechtes Beispiel für gute Softwarearchitektur bzw. es ist ein brilliantes Beispiel dafür, was man alles nicht machen soll. Wie z.B. URLs oder Pfade der Installation in die Datenbank schreiben. Und das auch noch in serialisierten PHP Arrays. Ansonsten ist die bitemporale Datenhaltung in SQL Datenbanken ein seit langem gelöstes Problem.
• Workflow-Management über git sign off et al.: Was daran jetzt leichter sein soll als den Workflow eines ausgewachsenen CMS zu nutzen weiß ich nicht. Gute CMSse bieten dieses Feature von Hause aus an.

Nesta CMS verwaltet seinen Content, wie ich auf der Webseite gelesen habe, in Markdown Dateien in einem separaten Verzeichnisbaum. Dieser Baum bildet dann nachher die URL-Pfade online ab. Ich werde wohl nie verstehen, warum man eine Markup-Sprache (HTML) durch eine andere (Markdown) ersetzt. Im Zweifelsfall stehen mir diese Dinger im Weg. Das Argument, daß ja nur ein bestimmtes erlaubtes Subset von HTML aus der anderen Markupsprache in HTML übersetzt wird und damit für mehr Sicherheit gesorgt wird ist ja auch nur ein gewisses Scheinargument. Das steht und fällt mit der Güte des Parsers.

Für größere Unternehmen eigent sich so ein filebasiertes CMS eher nicht, weil man hier z.T. zeitgleiche Schreibzugriffe auf einzelne Dateien hat. Das funktioniert eher schlecht. Beim Lesen des Contents gehe ich mal davon aus, daß hier der Filesystem Cache Kollisionen verhindert bzw. Zugriffe beschleunigt.
Es gibt ja auch noch CMSse, die allen Content in einer Datei speichern. Die sind dann auch noch beim Lesezugriff langsam.
Mein Fazit: Nicht jedes CMS ist für alles und jeden geeignet. Da spielen faktische Rahmenparameter genau so eine Rolle wie der persönliche Gusto des Benutzers. An einer Evaluation verschiedener Kandidaten führt wohl kein Weg vorbei.