Bilder in (Firebird-)Datenbank speichern

[jobo]

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.

[TBx]

@jobo: Es tut mir leid, wenn Du Dich persönlich von meinem Post angegangen fühltest.
Dies war nicht meine Absicht.
Ich verwische allerdings keinesfalls Deine Argumente, ich gehe nur halt nicht wirklich mit ihnen mit.
Den Tutorials von Holger habe ich im Allgemeinen nichts hinzuzufügen, alles weiter wären Feinheiten, die im Einzelfall besprochen werden müssen. Daher werde ich das hier jetzt nicht weiter aufrollen.
Nur soviel: Der Ressourcenoverhead hält sich beim Firebird da sehr in Grenzen (eine richtige Konfiguration vorausgesetzt, die ich dem Kunden automatisch mitgebe) und an Geschwindigkeit steht der FB dem Filesystem da auch in nichts nach.

[jobo]

Ich fühle mich nicht persönlich angegangen. Alles gut.
Hier gibt es nun genug Material, was Interessenten als Anregung für eigene Überlegungen und Experimente nutzen können.