Bilder in der Datenbank speichern?

[Ludwigmller]

Guten Morgen,
Was ist der beste Weg Bilder zu speichern? Direkt in der Datenbank oder als Datei, und in der DB den Speicherort und Dateinamen ablegen?

Das Bild soll vom Benutzer über eine Weboberfläche (HTML, PHP) hochgeladen werden und mit Metadaten versehen werden.


Gruß Ludwig

 

[castorp]

Datenbank oder Dateisystem - beides ist möglich. Beides hat Vor- und Nachteile.

In den meisten Fällen dürfte die Speicherung im Dateisystem effizienter sein.
Hat aber z.B. den Nachteil, dass Du selber "aufräumen" musst. Das Speichern der Dateien kann nicht transaktional abgesichert sein und der Zugriff geht nicht über SQL (kann aber auch ein Vorteil sein). Auch beim Backup musst Du jetzt mit zwei Tools jonglieren (Dateisystem + Datenbank).

Im Dateisystem solltest Du Dir Gedanken darüber machen wie die Dateien auf Verzeichnisse verteilt werden. Ein einzelnes Verzeichnis mit Millionen von Dateien ist extrem unhandlich zu bedienen.

Wenn Du die Bilder in der Datenbank speicherst, hast Du den Vorteil das über Transaktionen absichern zu können. Du musst nach dem Löschen eines Datensatzes nicht noch im Dateisystem aufräumen und der Zugriff wird über die gleichen Berechtigungen kontrolliert wie der auf die dazu gehörigen Metadaten.

Allerdings können Webserver (z.B. Apache https, nginx) nicht mehr direkt auf die Bilder zugreifen um sie an den Browser ausliefern zu können. Bei Postgres hast Du auch das Problem, dass das Lesen jedes Bildes durch die "shared_buffers" geht und damit andere (wichtigere Daten) aus dem Cache schmeißen kann (bei anderen Datenbanksysteme kann man das z.B. konfigurieren ob der Inhalt von BLOB Spalten ge-cached werden soll).

 

[dabadepdu]

Ich würde noch ergänzen:
Man kann was die Verzeichnisse angeht vielleicht in die Richtung gehen, dass relative Formen genutzt werden. Linux ist jedenfalls sehr flexibel, externe FS zu mounten. Falls Dein System mal groß wird und sowieso aus dem Web angesprochen, bietet die Dateihaltung auf einem extra Fileserver mit Cache sicher etwas bessere Performance.
Es ist hilfreich, ein gutes Konzept zu den Dateinamen zu haben. Wie benennt der Server die für sich? Welche Zuordnngsmöglichkeiten (ID?) gibt es? Wie wird die Datei bei einem Download genannt? Wenn es mehr als ein schnöder Avatar ist, und der User die Dateien tatsächlich auch wieder runterladen kann, dann vielleicht mit dem Originalnamen oder jedenfalls nicht unbedingt mit dem Servernamen.
Mit oder auch ohne jegliche Art von Unterverzeichnis, eben auch wenn man die Verzeichnisstruktur darunter wechselt, sollte der Bildname eindeutig sein.
Ggf. musst Du Werkzeuge haben und eine klare Veranwortlichkeit um verlorene/gefundene Dateien zu identifizieren (Stichwort Transaktion von Castorp).
Z.B. Nextcloud scant das Filesystem und die Dateien werden dann in die DB aufgenommen / dem User angezeigt oder auch nicht mehr angezeigt, sind halt weg. Naheliegend, ist ja ein Filehost. Wie soll es bei Dir sein?

 

[ukulele]

Klingt in diesem Fall auch eher so das jeder User eine größere Zahl Bilder hoch laden oder verarbeiten soll. Wenn es jetzt nur ein Profilbild von begrenzter Größe wäre würde ich vielleicht zur DB neigen, wenn es aber darum geht viele Bilder zu verwalten wird das Dateisystem wohl einfach besser skalieren.

 

[Ludwigmller]

Es geht eher nicht um viele Bilder. Die Datenbank soll u. A. Daten wie Standort, Datum, und eine Kategoriezuordnung je Bild speichern.

 

[akretschmer]

Es geht eher nicht um viele Bilder. Die Datenbank soll u. A. Daten wie Standort, Datum, und eine Kategoriezuordnung je Bild speichern.

das sind dann Metadaten zu dem Bild, richtig?

Die Vor- und Nachteile hat ja @castorp (und andere) schon gut geschildert.