Article
1 comment

Ist ein CMS ohne Datenbank kein CMS?

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.

1 Comment so far

  1. Dein Fazit ist sicherlich richtig. Was die anderswo erwähnte geringe Verbreitung von Ruby angeht: Jede Organisation, die eine individuelle Entwicklung erstellen lässt, muss wissen, wie sie diese später weiter pflegen möchte. Wenn also PHP/Java/Erlang/whatever Knowhow im Haus vorhanden ist, ist damit auch das Werkzeug der Wahl ziemlich klar vorgegeben. In meinem Fall halt Ruby…

    “nicht schreibbar”:

    Es gibt keine Admin- oder Moderatorfunktion via http, die man absichern müsste. (Logins, Sessions, SSL etc). Da entfällt IMO ein Angriffsvektor, weil keine Daten von außen verarbeitet werden. Wer den Rechner (über andere Wege) hackt, hat eh gewonnen.

    “Dateiverwaltung vs schlecht gemachte Datenbanken”:

    WordPress ist zwar denkbar schlecht gemacht, aber auch erstaunlich weit verbreitet. Selbst bei Organisationen, die es besser wissen sollten und sich Alternativen leisten könnten. Die anderen (typo3! TYPO3!) OSS Vertreter sind häufig auch nicht besser. Daher erwähne ich es.

    “Workflow”:

    Das ist ja gerade mein Argument: Erwachsene CMS haben da eigene Mechanismen, die auch möglicherweise nicht schlecht sind. Man erkauft diesen Luxus jedoch mit deutlich 5- bis 6-stelligen Lizenzkosten. Wem das zu groß ist, der sollte lieber eine leichtgewichtigere Variante wählen, bevor man gar nichts in der Richtung hat. Leider passiert dann meistens in der Praxis letzteres.

    “Markup”:

    Ich kenne kaum jemanden, der nicht Entwickler ist und trotzdem halbwegs korrektes HTML zu schreiben in der Lage wäre. Solchen Leuten helfen Parser wie markdown, textile und andere.

    Und selbst für den Chefentwickler (mich grin ist es angenehm, keine spitzen Klammern, schließende Tags und anderen Mist notieren zu müssen, nur weil man ein wenig Text publizieren möchte. Für die Feinheiten schreibe ich dann wieder HTML, wobei ich selbst da inzwischen HAML bevorzuge. (Genau wie SASS statt CSS)

    Grüße!

    Reply

Leave a Reply

Required fields are marked *.