Deine Maxime mag für Dich gelten. Ich tendiere da eher zu der Äußerung von ibexpert, das muss von Fall zu Fall entschieden werden. (Bedeutet in der Praxis vielleicht auch eine vereinheitlichte, abgesprochene, abgestimmte, generalisierte Kompromisslösung.)
Deine Argumente verwischen auch meinen Kompromissvorschlag, das vielleicht Beste aus beiden Welten zu nehmen. Eine
DB die Zugriffssicherheit und Fehlerschutz bietet und ein Dateisystem hinter der
DB, das Schnelligkeit und Ressourceneffizienz bietet.
Datenbanken mit all ihrem Luxus kommen mit dem Preis des Ressourcenverbrauchs (Platz, Zeit). Die Existenz von noSQL Systemen ist der lebende Beweis dafür. Das gilt auch und besonders beim Backup bzw. noch mehr bei der Restauration eines Backups, am deutlichsten bei einem Point in Time Recovery mit sequentiellem Einspielen der Änderungen. Ich kenne die Mechanismen von
FB nicht sehr genau, aber bei anderen Systemen ist es meist so, dass parallel zu den Datenbankdaten auch Wiederherstellungsinformationen geschrieben werden, also eigentlich alles doppelt. Diese Daten werden dann wiederum beide durch Backupverfahren aufgegriffen.
Administrative Maßnahmen wie eine Auslagerung von Dateidaten in eine weitere
DB sind ebenfalls nicht ohne Fehlerpotential, besonders wenn es sich um manuelle Vorgänge handelt. Wie dabei ein Bildarchiv ständig Daten aufnehmen kann, aber nicht gesichert werden muss, erschließt sich anhand der Beschreibung auch nicht. Wenn das alles durchautomatisiert ist, meinetwegen auch okay. Einen hochperformanten Zugriff über FS und entsprechende Cachemechanismen habe ich damit immer noch nicht.
Herausragende Fehl“administration“ ist im Einzelfall erschreckend, aber das ist schwerlich ein Argument für oder gegen etwas. Ich kann für jedes Verfahren irgendwelchen Irrsinn finden, der es beschädigt. Das ist natürlich alles relativ, aber Datenspeicherung per FS im direkten Zugriffsbereich des Endanwenders ist dagegen schon ziemlicher Horror. Ich habe jedenfalls in langer Praxis noch nicht erlebt, dass Administratoren eine Console öffnen, sich als
DB User oder als root an einem Server einer fremden Software anmelden und Dateien verschieben, verändern oder löschen.
Wenn durch ein
SQL Interface Daten in einem Server unerreichbar verschwinden und dahinter geschützt im Dateisystem gespeichert werden, ist es gut. Im Fall, den ich beschrieben habe, kann ich für jede Datei wählen oder grob konfigurieren, wo am Ende gespeichert wird, wenn ich möchte auch beides,
DB und FS. Das ist ja das Schöne, die Datenbank erlaubt einen sehr filigranen Umgang mit den hochgeladenen Daten. Das FS dahinter bringt einfach Speed und Raum für Nach- und Weiterverarbeitung mit einem riesigen Fundus an frei verfügbaren, fertigen Werkzeugen. Wer den puren Schutz in der
DB vorzieht, kann das so machen, sollte die Nebeneffekten aber wenigstens kennen.