[Grundsatzfrage] Bilder in DB oder am FS?

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/grundsatzfrage-bilder-in-db-oder-am-fs_221920/page_1 - zur Vollversion wechseln!

Obermotz schrieb am 27.01.2011 um 10:14

Hiho!

Hab ne Grundsatzfrage: Ist es heute bei der Webentwicklung eigentlich üblich, Bilder in der DB oder eher am FS zu speichern und in der DB die entsprechenden Referenzpfade zu speichern?

Vor/Nachteile?

Facebook zum Beispiel scheint sie ja auf dem FS liegen zu haben, OC.at scheint sie in der DB zu haben.

Punisher schrieb am 27.01.2011 um 10:21

kommt darauf an was dir wichtiger ist (zb größere Performance oder sturkturiertheit)

eine recht gute Zusammenfassung:

http://www.php-faq.de/q-db-blob.html

Smut schrieb am 27.01.2011 um 10:34

Zitat von Obermotz
Vor/Nachteile?

Facebook zum Beispiel scheint sie ja auf dem FS liegen zu haben, OC.at scheint sie in der DB zu haben.

ich würde sagen es ist genau umgekehrt.

z.b.:
http://www.overclockers.at/files/psp222_164103.png

Lizardking schrieb am 27.01.2011 um 11:14

ich würde bilder/files auf jeden fall ins fs legen und nur pfad-name in die db schreiben.

Zitat von Smut
ich würde sagen es ist genau umgekehrt.

z.b.:
http://www.overclockers.at/files/psp222_164103.png

nur weil png in der url steht heißt das nicht zwingend dass dort im fs auch ein bild liegt. (php, mod_rewrite...)

mat schrieb am 27.01.2011 um 11:17

Definitiv im Filesystem. Das Caching ist einfach weitaus besser! Das hindert dich natürlich nicht daran, parallel Referenzen in der Datenbank zu verwalten. Genau so funktioniert es auch hier im Forum, wobei wir die Funktionalität extra dazucoden mussten.

Rektal schrieb am 27.01.2011 um 17:57

Quintessenz? Beides =)

COLOSSUS schrieb am 27.01.2011 um 18:03

Im Dateisystem - alles andere ist grober Missbrauch. Generell werden fuer viel zu viele Dinge/Use Cases RDBMS (oder solche, die es noch werden wollen ) verwendet, wo es wirklich nicht sinnvoll oder gar noetig ist.

@Smut: ein URI hat semantisch rein gar nichts damit zu tun, wie die dadurch identifizierte Rescoure "erzeugt" (bzw. ausgelesen) wird. Das ist wissentlich und willentlich in der HTTP-Spezifikation so verbrieft, und auch gut so.

EG schrieb am 27.01.2011 um 18:09

[x] fs - dafür wurde es gemacht!

In einer Datenbank hast nur zusätzlichen Aufwand beim Reinschreiben und auslesen. Würd einfach einen Verweis (Name, ID, wie auch immer) in der Datenbank zum entsprechenden Bild am FS ablegen und den Rest der business logic überlassen.

Smut schrieb am 27.01.2011 um 18:34

Zitat von COLOSSUS
Im Dateisystem - alles andere ist grober Missbrauch. Generell werden fuer viel zu viele Dinge/Use Cases RDBMS (oder solche, die es noch werden wollen ) verwendet, wo es wirklich nicht sinnvoll oder gar noetig ist.

@Smut: ein URI hat semantisch rein gar nichts damit zu tun, wie die dadurch identifizierte Rescoure "erzeugt" (bzw. ausgelesen) wird. Das ist wissentlich und willentlich in der HTTP-Spezifikation so verbrieft, und auch gut so.

Ok. Mir ists mit file-Endung bisher noch nicht anders untergekommen. Zufälligerweise hat's in dem Fall halt gepasst.

djonny schrieb am 27.01.2011 um 19:53

Bin auch wie alle anderen der Meinung Bilder gehören am Filesystem abgelegt und der Pfad dorthin wird in die DB gespeichert

semteX schrieb am 27.01.2011 um 19:57

"kommt drauf an". binärdaten in der DB haben auch vorteile, zum beispiel transaktionsunterstützung und vergleichsweise einfache versionierungsmöglichkeit. weiters bringts der mssql server mittlerweile mit FILEPART zusammen, dass das ding zwar im FS direkt abgelegt wird, die referenz drauf aber in der db liegt. bei voller transaktionsunterstützung.

that schrieb am 27.01.2011 um 20:12

Zitat von semteX
"kommt drauf an". binärdaten in der DB haben auch vorteile, zum beispiel transaktionsunterstützung und vergleichsweise einfache versionierungsmöglichkeit. weiters bringts der mssql server mittlerweile mit FILEPART zusammen, dass das ding zwar im FS direkt abgelegt wird, die referenz drauf aber in der db liegt. bei voller transaktionsunterstützung.

Nicht zu vergessen, dass z.B. ein Backup einer Datenbank konsistent ist, selbst wenn währenddessen heftig in die DB geschrieben wird. Wenn die Datenbank aufs Filesystem verweist, muss man sich überlegen, wie man das beim Backup so synchron hinbekommt, damit es nach dem Restore wieder zusammenpasst.

Wenn man sich selbst um die Konsistenz bei Backup, Restore, Delete, Rollback usw. kümmern will, dann hat man dafür die Chance auf eine höhere Performance und weniger Troubles beim Zugriff auf die BLOBs.

Rektal schrieb am 28.01.2011 um 08:23

Sehe Ich wie semtex und that. Files sind primär in der DB und der dazwischen liegende Cache schreibt die aufs filesystem. Alles in der DB hat auch den vorteil für replikation auf andere systeme. Die frontend systeme entscheiden dann selbst wo die daten gecacht werden (fs, memcache). Gerade bilder müssen oft in verschiedenen auflösungen vorhanden sein. Original in DB, skalierte version auch mehrmals im frontend cache oder S3 oder ...

Neo-=IuE=- schrieb am 28.01.2011 um 08:34

ich glaub das hängt einfach alles sehr viel vom gewünschten verwendungszweck ab und kann nicht pauschalisiert werden

früher war es natürlich anders, weil die technik noch nicht so weit war, aber jetzt ist es wirklich anwendungs-spezifisch

watchout schrieb am 28.01.2011 um 23:39

Also für PHP/Apache würde ich - komplett Anwendungsneutral - empfehlen zumindest am FS zu Cachen, weil dann der Apache die HEAD Requests übernimmt und auch korrekt behandelt.

Ansonsten siehe Rektal, that, Semtex