nicht angemeldet MB
Linuchs
MB
Linuchs
Felix Riesterer
dedlfix
dedlfix
Felix Riesterer
MB
dedlfix
Camping_RIDER
MB
moin,
sollte man lieber nicht text basierende Daten (z.B. Bilder) lokal auf in htdocs/ abspeichern als in binärer Form in einer Datenbank? Ich weis nicht wie schnell die Antwort der lahmsten Datenbank aller Datenbanken ist, wenn man binäre Daten anfragt. Da wäre es schöner, denke ich mal, wenn man die binären Daten direkt Lokal auf htdocs/ hat. Soweit meine Überlegungen.
Welche Systeme bieten Sich an um diese Angelegenheiten auf der Datenbank Ebene zu erledigen und welche auf htdocs/?
lgmb
wieso sollten Felder mit binären Daten die DB verlangsamen? Es wird doch niemand in den binären Daten etwas suchen.
Möglicherweise eine Extra-Tabelle für die Bilder?
moin,
wieso sollten Felder mit binären Daten die DB verlangsamen?
z.B. User Avatars, Ausdrucks GIFs, Urlaubsfotos oder sonst was.
Es wird doch niemand in den binären Daten etwas suchen.
Sorry, checke ich nicht
lgmb
Es wird doch niemand in den binären Daten etwas suchen.
Sorry, checke ich nicht
Binäre Daten können - anders als ein Vorname und eine Artikelbezeichnung - wohl in die Millionen Bytes gehen, z.B. mp3
Was Zeit verbrät, ist doch die Suche nach Zeichenfolgen innerhalb der Daten. Wer wird das bei binären Daten denn machen?
Linuchs
hi @Linuchs
jede Datei ist eine Bytesequenz. Und selbstverständlich kann man in Bytesequenzen auch nach bestimmten Zeichenfolge suchen denn Zeichfolgen sind auch nur Bytzesequenzen.
Es ist jedoch so, daß ein Speichern in DB mehr Möglichkeiten bietet. Z.b. kann man beim Upload bestimmte Metadaten (Exif) rausziehen uind in dedizierten Feldern ablegen. Und wie ich schon schrieb, einen optionalen Titel und Beschreibung. Auf diese Felder eine Suchfunktion zu legen kann durchaus sinnvoll sein.
Und ja, Vorsicht beim Upload in und unterhalb DOCUMENT_ROOT! Man kann nämlich nicht sicherstellen, daß da nur Grafikdateien ankommen, jeder könnte da auch .js und .php Dateien hochladen die dann per Browser requestet werden können. Das Mindeste ist also, den Namen zu ändern.
Idee: Wenns unbedingt das FS sein soll, auch da könnte man eine Indexdatei anlegen. Oder die Metadaten nach DB schreiben und die Bilder in der DB referenzieren.
Hat alles seine Vor und Nachteile. Machen must Du'sowieso selber. MfG
Lieber pl,
Z.b. kann man beim Upload bestimmte Metadaten (Exif) rausziehen uind in dedizierten Feldern ablegen. Und wie ich schon schrieb, einen optionalen Titel und Beschreibung. Auf diese Felder eine Suchfunktion zu legen kann durchaus sinnvoll sein.
diese Felder benötigen aber keines, das den binären Dateiinhalt in Gänze enthält. Es ist ebenso gut möglich, zu den Metadatenfeldern noch ein Pfad-Feld zu speichern, welches die Datei im Dateisystem beschreibt. Dann liegt die Datei selbst eben doch nicht in der DB und die von Dir genannten Vorteile sind trotzdem verfügbar.
Und ja, Vorsicht beim Upload
Das ist ein grundsätzliches Problem und gehört zu den Hausaufgaben eines jeden Erstellers einer Webapplikation, dass er/sie hier sehr empfindlich auf Sicherheitsaspekte prüft.
Das Mindeste ist also, den Namen zu ändern.
Das halte ich für Blödsinn. Viel sinnvoller halte ich die Ausgabe der Datei durch ein passendes Script, welches dann eben "von Hand" tun muss, was ansonsten der Webserver "von Haus aus" tun könnte - wenn man keine Konfigurationsmöglichkeiten hat, dass er Scriptdateien dort bitte eben gerade nicht ausführen möge.
Oder die Metadaten nach DB schreiben und die Bilder in der DB referenzieren.
Siehste, jetzt biste bei mir - nur beschränke ich das nicht auf Bilder, sondern erweitere es auf alles.
Liebe Grüße,
Felix Riesterer.
Das Mindeste ist also, den Namen zu ändern.
Das halte ich für Blödsinn.
Genau das ist die Sicherheitslücke! Über den Namen kann man nämlich auch das Zielverzeichnis bestimmen! Im Übrigen muss man beim Upload sowieso sicherstellen daß ein Dateiname bestimmten Konventionen genügt. Das ist also ein Aufwasch.
Viel sinnvoller halte ich die Ausgabe der Datei durch ein passendes Script, welches dann eben "von Hand" tun muss, was ansonsten der Webserver "von Haus aus" tun könnte
Einem Hacker ist das völlig egal. Er platziert ein agent.php unterhalb der Docroot und kann dann in aller Ruhe sein Unwesen teiben.
Und was den Namen betrifft: Bei einer DB gestützten Anwendung kriegt die Datei als Name einfach die ID vom auto_increment, fertig.
Tipp: Benutze die FileAPI zum Upload, die liefert neben type auch mtime und size zur jeweiligen Datei.
MfG
Lieber pl,
Im Übrigen muss man beim Upload sowieso sicherstellen daß ein Dateiname bestimmten Konventionen genügt.
davon gehe ich grundsätzlich aus. Slashes in jeder Richtung sind z.B. schlicht verboten.
Einem Hacker ist das völlig egal. Er platziert ein agent.php unterhalb der Docroot und kann dann in aller Ruhe sein Unwesen teiben.
Ähm... wie soll denn agent.php ausgeführt werden? Durch welchen Request wird das vom Server tatsächlich aufgerufen, wenn die Ausgabe der Datei an den Browser durch ein Script geschieht, da die Adresse nicht über die URL erreichbar ist?
Und was den Namen betrifft: Bei einer DB gestützten Anwendung kriegt die Datei als Name einfach die ID vom auto_increment, fertig.
Klar. Je nach Anwendung kann das sogar sinnvoll sein, gerade wenn man verschiedene Versionen ein und derselben Datei vorhalten können will.
Tipp: Benutze die FileAPI zum Upload, die liefert neben type auch mtime und size zur jeweiligen Datei.
FileAPI? Du meinst bestimmt File Information, Du alter PHP-ler. ;-)
Liebe Grüße,
Felix Riesterer.
Im Übrigen muss man beim Upload sowieso sicherstellen daß ein Dateiname bestimmten Konventionen genügt.
davon gehe ich grundsätzlich aus. Slashes in jeder Richtung sind z.B. schlicht verboten.
Einem Hacker ist das völlig egal. Er platziert ein agent.php unterhalb der Docroot und kann dann in aller Ruhe sein Unwesen teiben.
Ähm... wie soll denn agent.php ausgeführt werden?
Indem er es requestet: http://example.com/agent.php
Im Übrigen werden PHP Dateien nicht ausgeführt sondern der darin enthaltene PHP Code.
FileAPI? Du meinst bestimmt File Information, Du alter PHP-ler. ;-)
Nein nix PHP. Ich meine schon die FileAPI im Browser. Was natürlich serverseitig auch zu verarbeiten wäre was man damit sendet.
MfG
Hallo pl,
Im Übrigen werden PHP Dateien nicht ausgeführt sondern der darin enthaltene PHP Code.
Dann werden auch keine exe-Dateien ausgeführt sondern der darin enthaltene Code.
Bis demnächst
Matthias
Lieber pl,
Indem er es requestet: http://example.com/agent.php
das kann er nur, wenn diese Datei über die URL erreichbar ist. Liegt sie außerhalb des Document_Root, ist das eben nicht möglich. Daher auch die Empfehlung, Dateien so abzuspeichern, dass sie mit einer URL nicht erreichbar sind.
Und gegen Angriffe wie http://example.org/../../../../../../../../etc/.shadow sollte es längst wirkungsvolle Mechanismen geben, für die der Hoster zuständig ist, nicht das Script-Kiddie, das ein Upload-Spielchen baut.
Liebe Grüße,
Felix Riesterer.
Tach!
sollte man lieber nicht text basierende Daten (z.B. Bilder) lokal auf in
htdocs/abspeichern als in binärer Form in einer Datenbank?
Ohne die konkrete Anwendung und deren Bedürfnisse zu kennen, kann ich dazu keine definierte Antwort geben.
Ich weis nicht wie schnell die Antwort der lahmsten Datenbank aller Datenbanken ist, wenn man binäre Daten anfragt.
Da wird es keinen Unterschied zu anderer Arten von Daten geben.
Da wäre es schöner, denke ich mal, wenn man die binären Daten direkt Lokal auf
htdocs/hat. Soweit meine Überlegungen.
Direkt auslieferbare Daten, egal ob binär oder anders, sind prinzipiell schneller ausgeliefert, wenn sie der Webserver direkt lesen und versenden kann. Das heißt aber nicht, dass sie ausschließlich im Dateisystem liegen müssen. Man kann sie ja trotzdem im DBMS verwalten, und im Filesystem einen Cache anlegen, aus dem sich der Webserver bedient. Wenn die angefragte Datei noch nicht dort vorhanden ist, kann man ja ein Script aufrufen, das die Datei besorgt und ausliefert und für nachfolgende Requests in den Cache schreibt.
Welche Systeme bieten Sich an um diese Angelegenheiten auf der Datenbank Ebene zu erledigen und welche auf
htdocs/?
Das wird eine Entscheidung nach Vorliebe sein. Ob man lieber den Datenbestand im DBMS haben möchte oder zusätzlich zu den DBMS-Daten noch Daten in Form von Dateien rumliegen haben möchte (abgesehen vom Cache).
dedlfix.
kommt darauf an was Du mit den Daten machen willst. Ich nehme mal an die soll der Webserver ausliefern. Da wird der Webserver selbst einen Last-Modified Header generieren anhand des Dateidatum wenn die im Dateisystem liegen.
Hast Du die Images jedoch in einer DB, must Du Dich selbst ums Cachen kümmern. Was aber auch kein Problem ist, wenn zum Image ein Zeitstempel vorhanden ist.
Und dann kommts noch darauf an, wo die Images herkommen. Falls das Uploads sind, ist das Speichern in DB sicherer als das Speichern im FS. Gib den Images fortlaufende Nummern und erfasse auch den Content-Type. Optional einen Titel und eine Beschreibung.
MfG
Tach!
Und dann kommts noch darauf an, wo die Images herkommen. Falls das Uploads sind, ist das Speichern in DB sicherer als das Speichern im FS.
Inwiefern? Sicherheit ist kein Absolutum. Für welche Situationen/Handlungen/wasauchimmer ist das DBMS deiner Meinung nach sicherer als das Filesystem?
dedlfix.
Moin,
Und dann kommts noch darauf an, wo die Images herkommen. Falls das Uploads sind, ist das Speichern in DB sicherer als das Speichern im FS.
Ich bitte Dich. Quatsch mit Soße.
Lieber MB,
Dateien, die ein User herunterladen können soll, speichere ich im Dateisystem des Webservers. Wenn Dateien anhand von Berechtigungen verfügbar oder gerade nicht verfügbar sein sollen, dann sind sie in einem vom Browser nicht direkt erreichbaren Verzeichnis und werden durch ein Script an den Browser ausgeliefert, welches die Berechtigungen berücksichtigt.
Genau hier könnte man nun auch aus der Datenbank die binären Daten ausgeben. Aber der Rest meiner Daten in der DB ist so schön klein und handlich (wenn gezippt), da hätte ich ein zigfaches Datenvolumen, wenn ich einen Dump erzeugen muss (z.B. als Archiv oder Snapshot o.ä.) - also doch lieber binäre Daten im Dateisystem und Verweise dazu entweder in der DB, oder direkt aus dem Verzeichnislisting einer passenden Funktion meiner Scriptsprache. Ich empfinde es einfach als handlicher! Und das Backup des Hosters kann Dateien ebenso wunderbar wieder herstellen, wie Dumps. Aber wenn alle Dateien im Dump beinhaltet sind, wie stelle ich da eine einzelne wieder her? Da müsste ich aus dem Dump die binären Daten herauspopeln, um dann in der entsprechenden Tabelle diese wieder einzulesen... ach, da mache ich lieber eben mal FTP/sFTP/SCP/whatever.
Liebe Grüße,
Felix Riesterer.
moin,
Vielen Dank für den einblick.
lgmb
Hey Felix,
Dateien, die ein User herunterladen können soll, speichere ich im Dateisystem des Webservers. Wenn Dateien anhand von Berechtigungen verfügbar oder gerade nicht verfügbar sein sollen, dann sind sie in einem vom Browser nicht direkt erreichbaren Verzeichnis und werden durch ein Script an den Browser ausgeliefert, welches die Berechtigungen berücksichtigt.
ich will nicht pingelig sein, aber ein Dateisystem des Webservers gibt es nicht.
Genau hier könnte man nun auch aus der Datenbank die binären Daten ausgeben. Aber der Rest meiner Daten in der DB ist so schön klein und handlich (wenn gezippt), da hätte ich ein zigfaches Datenvolumen, wenn ich einen Dump erzeugen muss (z.B. als Archiv oder Snapshot o.ä.) - also doch lieber binäre Daten im Dateisystem und Verweise dazu entweder in der DB, oder direkt aus dem Verzeichnislisting einer passenden Funktion meiner Scriptsprache. Ich empfinde es einfach als handlicher! Und das Backup des Hosters kann Dateien ebenso wunderbar wieder herstellen, wie Dumps. Aber wenn alle Dateien im Dump beinhaltet sind, wie stelle ich da eine einzelne wieder her? Da müsste ich aus dem Dump die binären Daten herauspopeln, um dann in der entsprechenden Tabelle diese wieder einzulesen... ach, da mache ich lieber eben mal FTP/sFTP/SCP/whatever.
Na ja. Auf alle Fälle sollte man binäre Daten in diesen Mengen nicht in der DB speichern. Einfach weils Unfug ist, mehr muss man dazu nicht sagen. Wer schonmal mit DB-Dumps zu tun hatte, in denen gigabyteweise binäre Daten hinterlegt waren, der weiß, warum man das nicht tun sollte.
Grüße an die Erdlinge und sonstwie blauen Füchse Otto Katz, I (Zentralbatz)
.
Lieber Otto,
ich will nicht pingelig sein,
warum bist Du's dann trotzdem?
aber ein Dateisystem des Webservers gibt es nicht.
Dann eben "Dateisystem des Hosts". Besser?
Auf alle Fälle sollte man binäre Daten in diesen Mengen nicht in der DB speichern. Einfach weils Unfug ist, mehr muss man dazu nicht sagen.
Sehr qualitativ hochwertige Antwort. Ein Basta! hat schon immer das Verstehen weit voran gebracht.
Wer schonmal mit DB-Dumps zu tun hatte, in denen gigabyteweise binäre Daten hinterlegt waren, der weiß, warum man das nicht tun sollte.
Genau das war doch der Kern meiner Argumentation. Warum müssen es denn gigabyteweise Datenmengen sein? Manchmal genügen schon wenige Megabyte, wenn man einen Dump einspielen will und PHP (ich nutze sehr gerne phpMyAdmin) ein Upload-Limit hat.
Otto Katz, I (Zentralbatz)
Schon klar.
Liebe Grüße,
Felix Riesterer.
Hi Felix,
ich will nicht pingelig sein,
warum bist Du's dann trotzdem?
Du willst also, dass Falschinformation in einem Fachforum die Runde macht? Es gibt hier auch Anfänger, die Euch Experten vertrauen.
aber ein Dateisystem des Webservers gibt es nicht.
Dann eben "Dateisystem des Hosts". Besser?
Viel besser!
Auf alle Fälle sollte man binäre Daten in diesen Mengen nicht in der DB speichern. Einfach weils Unfug ist, mehr muss man dazu nicht sagen.
Sehr qualitativ hochwertige Antwort. Ein Basta! hat schon immer das Verstehen weit voran gebracht.
Reine Schreibfaulheit. Kann man doch alles im Interdings nachlesen oder halt mal selber machen und auf die Schnauze fallen.
Wer schonmal mit DB-Dumps zu tun hatte, in denen gigabyteweise binäre Daten hinterlegt waren, der weiß, warum man das nicht tun sollte.
Genau das war doch der Kern meiner Argumentation. Warum müssen es denn gigabyteweise Datenmengen sein? Manchmal genügen schon wenige Megabyte, wenn man einen Dump einspielen will und PHP (ich nutze sehr gerne phpMyAdmin) ein Upload-Limit hat.
Ja klar, hab auch nichts anderes behauptet, oder?
Otto Katz, Kaubatz a la Pastrami
Tach!
Genau hier könnte man nun auch aus der Datenbank die binären Daten ausgeben. Aber der Rest meiner Daten in der DB ist so schön klein und handlich (wenn gezippt), da hätte ich ein zigfaches Datenvolumen, wenn ich einen Dump erzeugen muss (z.B. als Archiv oder Snapshot o.ä.)
Das hört sich ein bisschen nach Milchmädchenrechnung an. Wenn die Dateien zum Datenbestand dazugehören, dann sollte man sie nicht auf diese Weise wegrechnen. In ein Backup gehören sie auf alle Fälle mit hinein.
Ich empfinde es einfach als handlicher!
Ich meine, das kommt immer auf die Szenarien an, die man abzudecken gedenkt. Wenn ich die Daten eines Nutzers wiederherstellen möchte, weil er zum Beispiel was unbeabsichtigt überschrieben hat, dann ist die Größe des Datebestands das kleinste der Probleme. Vielmehr hat man die Arbeit, die Daten herauszusuchen, besonders wenn sie sich über mehrere Tabellen verteilen. Aber alle Datensätze zu einer User-ID (innerhalb einer Tabelle) lassen sich letztlich einfacher selektieren als ein paar Dateien einzeln zusammenzusuchen. Einfacher wird es, wenn man sie nach Nutzern getrennt in Unterverzeichnissen hat. Das nützt aber auch nicht viel, wenn nur bestimmte Dat(ei)en wiederhergestellt werden sollen, dann muss man wohl doch eher mit Handarbeit ran. Bei Datensätzen hat man immerhin noch die Chance, dass man ein geeignetes Selektionskriterium formulieren kann, vor allem, wenn Metadaten zu berücksichtigen sind, die nicht im Dateinamen enthalten sind.
Dazu kann man sich sicher noch mehr Szenarien ausdenken oder aus dem Erfahrungsnähkästchen ziehen. Am Ende hat man sich sowieso für das ungünstigere Ordnungssystem entschieden. Murphy sei Dank.
Und das Backup des Hosters kann Dateien ebenso wunderbar wieder herstellen, wie Dumps. Aber wenn alle Dateien im Dump beinhaltet sind, wie stelle ich da eine einzelne wieder her?
Eine Möglichkeit ist, das Backup in eine temporäre Datenbank einzuspielen, eine Abfrage mit phpMyAdmin zu formulieren, das Ergebnis zu exportieren, und dann hat man einen kleineren Dump mit den betroffenen Daten.
Da müsste ich aus dem Dump die binären Daten herauspopeln, um dann in der entsprechenden Tabelle diese wieder einzulesen... ach, da mache ich lieber eben mal FTP/sFTP/SCP/whatever.
Wenn das in deinen Fällen imer so einfach geht, dann ist das auch gut.
dedlfix.
Aloha ;)
@EDIT: Unterm Strich hat @dedlfix bereits alles geschrieben was ich sagen wollte - ich habe sein Posting nur übersehen.
Ich stimme dir zu. Allerdings möchte ich hier...
Genau hier könnte man nun auch aus der Datenbank die binären Daten ausgeben. Aber der Rest meiner Daten in der DB ist so schön klein und handlich (wenn gezippt), da hätte ich ein zigfaches Datenvolumen, wenn ich einen Dump erzeugen muss (z.B. als Archiv oder Snapshot o.ä.) - also doch lieber binäre Daten im Dateisystem und Verweise dazu entweder in der DB, oder direkt aus dem Verzeichnislisting einer passenden Funktion meiner Scriptsprache. Ich empfinde es einfach als handlicher!
...kurz einhaken. Ein Dump, den du erzeugst - als Snaphshot oder als Archiv - sollte ja grundsätzlich den gesamten Zustand der Nutzerdaten (oder auch Konfigurations- oder wie auch immer -Daten) zu einem bestimmten Zeitpunkt abbilden.
Bei einer Lösung, die Bilder etc. im Dateisystem des Webservers[1] ablegt, muss man fairerweise zu diesem DB-Dump auch eine Kopie der im Dateisystem abgelegten Daten ablegen und erhält dann natürlich in Summe die selbe Dateigröße z.B. eines ZIP-Archivs, das dann den Snapshot darstellt.
Und das Backup des Hosters kann Dateien ebenso wunderbar wieder herstellen, wie Dumps. Aber wenn alle Dateien im Dump beinhaltet sind, wie stelle ich da eine einzelne wieder her? Da müsste ich aus dem Dump die binären Daten herauspopeln, um dann in der entsprechenden Tabelle diese wieder einzulesen... ach, da mache ich lieber eben mal FTP/sFTP/SCP/whatever.
Hm, aber auch aus einem ZIP-Archiv, das den Snapshot darstellt, muss ich das einzelne Bild wieder herauspopeln. Das Backup des Hosters ist mMn ein verhältnismäßig schwaches Argument, denn nicht jeder Hoster bietet den gleichen Service und manch Hoster-Backup einzuspielen ist ein schwierigerer Prozess als das Herauspopeln von binären Daten aus einem Dump.
Das heißt nicht, dass dein Argument deshalb falsch ist. Ich würde aber beim selben Argument etwas anderes in den Fokus rücken. Wenn man vom fehlenden Bild weiß, wie es aussieht, ist es relativ einfach, das Bild in der ZIP-Datei wiederzufinden. Im binären Datendump ist der Wiedererkennungswert - wie soll ich sagen - nicht ganz so hoch.
Also ja, auf voller Linie - ich würde solche Daten auch nicht in der Datenbank speichern wollen, und deine Argumente sehe ich auch. Ich empfinde allerdings den Vorsprung der einen Herangehensweise vor der anderen als nicht ganz so krass wie mir das beim Lesen deiner Argumente vorkam, deshalb mein kleiner Dämpfer, auch wenn ich der Richtung nach völlig bei dir bin.
Grüße,
RIDER
Du kannst die Bilder auch unter hwox/ ablegen. Oder yuux/ ist auch nicht schlecht. Du weisst, was ich meine?
moin,
Du kannst die Bilder auch unter hwox/ ablegen. Oder yuux/ ist auch nicht schlecht. Du weisst, was ich meine?
leider nicht nein? Erläuter mir
lgmb
Warum willst du denn eigentlich binäre Daten in der DB speichern? Hat das einen speziellen Grund?
moin,
Warum willst du denn eigentlich binäre Daten in der DB speichern? Hat das einen speziellen Grund?
Z.B. wie schon von mir erwähnt User-Avatare, Urlaubsfotos von Useren usw.
lgmb
Hallo
Warum willst du denn eigentlich binäre Daten in der DB speichern? Hat das einen speziellen Grund?
Z.B. wie schon von mir erwähnt User-Avatare, Urlaubsfotos von Useren usw.
Das mag das Was sein, es beantwortet aber unter keiner Bedingung die Frage nach dem Warum.
Tschö, Auge
sollte man lieber nicht text basierende Daten (z.B. Bilder) lokal auf in
htdocs/abspeichern als in binärer Form in einer Datenbank?
m.E. nach gehören Bilder/Videos & Co in 99% der Fälle ins Dateisystem. Wie hier schon erwähnt, muss man einigen Aufriss betreiben, um die Nachteile (Caching, Header, Serverlast) der Ablage in der DB zu kompensieren.
sollte man lieber nicht text basierende Daten (z.B. Bilder) lokal auf in
htdocs/abspeichern als in binärer Form in einer Datenbank?m.E. nach gehören Bilder/Videos & Co in 99% der Fälle ins Dateisystem. Wie hier schon erwähnt, muss man einigen Aufriss betreiben, um die Nachteile (Caching, Header, Serverlast) der Ablage in der DB zu kompensieren.
Und warum nur Bilder/Videos & Co ins Dateisystem? Es gibt jede Menge Entwickler die speichern text/html Dateien massenweise in Datenbanken und nehmen die von Dir genannten Nachteile offensichtlich gerne in Kauf. Wobei es programmiertechnisch gar keinen Unterschied gibt ob ein HTML Template oder ein GIF aus MySQL gelesen wird.
MfG
Und warum nur Bilder/Videos & Co ins Dateisystem?
Hätte auch schreiben können: statische Files.
Es gibt jede Menge Entwickler die speichern text/html Dateien massenweise in Datenbanken und nehmen die von Dir genannten Nachteile offensichtlich gerne in Kauf.
Wenn es dafür gute Gründe gibt: gerne. Bei GIF sehe ich das für den Standardfall (öffentlich erreichbare Ressource) nicht.
Wobei es programmiertechnisch gar keinen Unterschied gibt ob ein HTML Template oder ein GIF aus MySQL gelesen wird.
Klar. Bei einem HTML-Template ist das ja auch sinnvoll, weil es vermutlich vor der Ausgabe an den Client mit dynamischen Inhalten angereichert wird. Bei einem statischen(!) GIF ist das nicht der Fall. Ergo würde man dem Webserver im Vergleich zu einem statischen File das zigfache an Last aufbürden, um die Ressource an den Client auszuliefern. Nicht gut. Klar, das kann man nun mittels Caching lösen, indem man das File bei Bedarf erzeugt und im Filesystem ablegt. Dann muss man sich aber drum kümmern, den Cache zu invalidieren, wenn sich der Inhalt des Bildes ändert. Um die Header muss man sich auch noch kümmern. Ganz schön viel Aufriss für eine statische Ressource, die der Webserver von Haus aus umfassend und schnell behandelt.
Wobei es programmiertechnisch gar keinen Unterschied gibt ob ein HTML Template oder ein GIF aus MySQL gelesen wird.
Klar. Bei einem HTML-Template ist das ja auch sinnvoll, weil es vermutlich vor der Ausgabe an den Client mit dynamischen Inhalten angereichert wird.
Warum sollte das ein Argument pro DB sein? Da muss das Template ja ersteinmal reinkommen, also brauchts ein Backend zum Erstellen+Bearbeiten. Da ist doch viel einfacher, HTML Templates als Dateien abzulegen.
Bei einem statischen(!) GIF ist das nicht der Fall. Ergo würde man dem Webserver im Vergleich zu einem statischen File das zigfache an Last aufbürden, um die Ressource an den Client auszuliefern.
Ein HTML Template durchläuft zum Rendern auch den Hauptspeicher und auch dann wenn es aus dem Dateisystem geladen wird.
Nicht gut. Klar, das kann man nun mittels Caching lösen, indem man das File bei Bedarf erzeugt und im Filesystem ablegt. Dann muss man sich aber drum kümmern, den Cache zu invalidieren, wenn sich der Inhalt des Bildes ändert. Um die Header muss man sich auch noch kümmern. Ganz schön viel Aufriss für eine statische Ressource, die der Webserver von Haus aus umfassend und schnell behandelt.
Ein Webserver erstellt den Last-Modified oder FileEtag Header anhand mtime einer Datei. Diesen Header selbst zu erzeugen, ist überhaupt kein Aufwand, vorausgesetzt man hat die mtime.
Also insgesamt überzeugen Deine Argumente nicht wirklich. MfG
Da ist doch viel einfacher, HTML Templates als Dateien abzulegen.
Na! Das dauert dann aber nicht lange genug, das geht doch ohne Datenbank viel zu schnell! Sowas verhält sich wie bei dem einstmals genialen, von Marx, Engels und Lenin entwickeltem Marketing für Trabant oder Wartburg: Kaum hatten die aus dem Westen herbeigeholten Trottel von der Treuhand das Pre-Sale-Waiting von 9 bzw. 16 Jahren abgeschafft wollte niemand mehr diese modernen und fortschrittlichen, aber nur noch nicht in allen Belangen perfekten Fahrzeuge (mit denen man, mit ein wenig Glück, die ganze DDR an einem einzigen Tag durchqueren konnte - falls man an den Tankstellen weniger als 3 Stunden anstand!) dem IFA-Vertrieb abkaufen! Vorher wollte das praktisch jeder! Der Preis war praktisch egal!
Abgeleiteter Merksatz:
Kaum hatten die aus dem Westen herbeigeholten Trottel von der Treuhand
Ne, das waren keine Trottel. Die Liquidierung der DDR war von langer Hand geplant bis ins kleinste Detail. Wir vom Erfurter Bürgerkomitee konnten da nur noch fassungslos zuschauen wie innerhalb kürzester Zeit ein ganzes Ministerium in Privatunternehmen verwandelt wurde.
Wobei ganz offensichtlich dieser und weitere Pläne in diesem Ministerium selbst entwickelt wurden, dafür gibt es mehr als nur Indizien, aber mit der Treuhand kamen bekanntlich auch die Aktenvernichter und Geschichtsfälscher.
das Pre-Sale-Waiting von 9 bzw. 16 Jahren abgeschafft wollte niemand mehr diese modernen und fortschrittlichen, aber nur noch nicht in allen Belangen perfekten Fahrzeuge (mit denen man, mit ein wenig Glück, die ganze DDR an einem einzigen Tag durchqueren konnte - falls man an den Tankstellen weniger als 3 Stunden anstand!) dem IFA-Vertrieb abkaufen! Vorher wollte das praktisch jeder! Der Preis war praktisch egal!
Die mit der sog. Wende verbundenen Preisverluste waren denen ja auch egal. Ein Trabi, heute für 13T Märker fabrikneu erworben war praktisch am nächsten Morgen nichts mehr wert. Wobei Verluste dieser Art noch das kleinere Übel waren.
Und bitte nicht vergessen, auch wenn wir heute mit dem Mercedes in den Thüringer Wald fahren: Es waren auch IFA Fahrzeuge, Wartburg und Trabi die Millionen Menschen ermöglichten das Fahren zu lernen!
MfG
Ein Trabi, heute für 13T Märker fabrikneu erworben
Grundpreis war doch 8900 MdDDR. Du hast sicherlich die de-Luxe-Version mit Sportlenkrad, zwei Rückspiegeln, Metallfelgen, Radialreifen, 6-Punkt-Fixgurtsystem für Fahrer und Beifahrer in der Sonderlackierung "Eisblau" (nur ganz wenige nannten das "Schlüpferblau"), der als Spazierstock nutz- und also entnehmbaren Aluminium-Schaltstange, der bis heute für ihre Sicherheit bekannten 6V-Elektrik und natürlich der Radiovorbereitung gemeint.
So einen hatte ich auch.
war praktisch am nächsten Morgen nichts mehr wert
Je nach Sicht. Der Gebrauchswert blieb ja erhalten. Immerhin bin ich in einer Nacht mit dem bis in den Allgäu gekommen, das schaffen heute nur ca. 20% aller Bundeswehrhubschrauber! Nur zwei Tage später konnte ich wieder hören.
mit dem Mercedes in den Thüringer Wald
Mercdes-Benz? Lächerliche Kutschen! Wenn ich sowas fahren will, dann rufe ich (genau wie Kreti und Pleti) ein beschissenes Taxi!
Ich fahre Bombardier-Siemens. Viel länger, viel breiter, viel höher, das zigfache an Motorleistung, rein elektrisch, Wlan, reservierten Parkplätzen in fast allen Großstädten (außer Chemnitz!), sogar wichtigen Dörfern (solchen, deren Bürgermeister mit den richtigen Leuten saufen oder wo die Verkehrsminister ihren Wahlkreis haben: Oberau, Züssow, Montabaur, Limburg ), Platz zum Auf-und abgehen - und vor allem mit einem ausgewachsenem Restaurant onboard!
Nun, mit Deiner Entscheidung die Bahn zu nehmen wirst Du die Überproduktion an PKW und die damit verbundene Umweltzerstörung auch nicht verhindern. Die sogar schon soweit geht, daß Neuwagen unverkauft und massenweise wieder verschrottet werden damit die Verkaufspreise für den Rest ja nicht fallen.
MfG
Der Mitleser schrieb
Bilder/Videos & Co in 99% der Fälle ins Dateisystem.
Vermutlich hat er mit "& Co." statisches Zeug gemeint, welches nicht durchsucht wird, eine gewisse Größe hat (512 Byte, also Standard-Blockgröße vieler Geräte wäre schon mal ein Anhaltspunkt) und über Key-Value-Abhängigkeit geholt werden kann(Key als Bestandteil des Dateinamens).
Er hat aus meiner Sicht die von die angeführten HTML-Templates nicht ausgeschlossen. Mit dem "warum nur" willst Du vom Mitleser eine Begründung für etwas, was er nicht behauptet hat.
Es gibt jede Menge Entwickler die speichern text/html Dateien massenweise in Datenbanken und nehmen die von Dir genannten Nachteile offensichtlich gerne in Kauf. Wobei es programmiertechnisch gar keinen Unterschied gibt ob ein HTML Template oder ein GIF aus MySQL gelesen wird.
Des Pudels Kern ist doch das hier: "nehmen die von Dir genannten Nachteile offensichtlich gerne in Kauf". Wenn ich einen Nachteil in Kauf nehme, dann doch nur wenn ich dadurch einen Vorteil habe, der den Nachteil überwiegt. Ob ich mich bei den unbekannten Projekten der von Dir genannten anonymen Entwickler deren Meinung anschließen würde, dass die Vorteile die Nachteile überwiegen, steht in den Sternen.
Ganz generell würde ich dazu neigen, Bilder ins Dateisystem zu legen. Ein guter Grund die in einer Datenbank abzulegen könnte z.B. eine Datenanreicherung mit durchsuchbaren Meta-Daten und geforderte referentielle Integrität (Hier: "Bild nicht löschbar, wenn in Nachricht enthalten") sein. Doch selbst dann muss man überlegen, ob die Grafik wirklich in eine Datenbank muss:
Ein Beispiele dafür, dass das trotz teilweiser "referentieller Integrität" nicht sein muss:
Nehmen wir mal eine Nachrichtenseite. Aus irgendwelchen Gründen soll die Gesamtgröße der Daten unter /var/www/htdocs (dto:/var/lib/mysql, die Ordner sind nur ein Beispiel) eine gegebene und knappe Größe nicht überschreiten. Jetzt sollen also irgendwann Nachrichten gelöscht werden (können), damit Platz für neue Nachrichten wird. So der Plan (hoffentlich bevor die Seite erstellt wurde, 3 Jahre am Netz und der Platz wegen der 10000 Nachrichten mit 25000 Bildern - zusammen sind das bei 40 KB pro Bild rund 1 GB - knapp ist...).
Zu den Nachrichten gehören jeweils kein, ein oder einige Fotos. Die Fotos wieder können zu einer oder mehreren Nachrichten gehören.
Jetzt stellt sich die Frage, wie man sicherstellt, dass Nachrichten und NUR die nicht mehr verwendeten Fotos gelöscht werden. Mit der Datenbank ist das relativ einfach und man könnte sagen "Ok. Ich nehme hier die Nachteile der Speicherung in der Datenbank in Kauf."
Kommt die Regina Schaukrug vorbei, und sagt: "Wieso? Das Dateisystem ist "(NoSQL-Datenbank genug" Das geht also auch anders:"
Matthias Apsel
Auge
Rolf Bln /var/www/image-dir/bild.png /var/www/htdocs/image-dir/nachricht-0815-03.png
Der Link-Zähler der Datei /var/www/image-dir/bild.png steht jetzt auf 2, der Speichermehrverbrauch? Ein paar handverlesene Bytes.
-rw-r--r-- 2 USER GROUP 7582 Okt 7 12:21 bild.png
Mit etwas wie
ls -l bild.png | cut -d " " -f2
bekommt man übrigens die 2, also den Linkzähler. In PHP mit:
echo lstat('bild.png')['nlink'];
Wenn man die Nachricht löscht, dann löscht man auch die Links zu den zugehörigen Bildern:
rm -f /var/www/htdocs/image-dir/nachricht-0815-*.png;
Der Linkzähler steht im Beispiel jetzt auf 1.
-rw-r--r-- 1 USER GROUP 7582 Okt 7 12:21 bild.png
Das Löschen nicht mehr verlinkter, also nicht benötigter Bilder ist dann mittels Shell-Befehl einfach:
cd /var/www/image-dir;
find -name "*.png" -links 1 -exec rm -f "{}" \;;
findet jedes Bild, welches nur einen Link hat, also in keiner Nachricht mehr vorkommt und löscht es, auf das, wie gefordert Licht Platz werde. Sollten extrem viele Bilder gelöscht werden müssen, dann
find -name "*.png" -links 1 -print0 | xargs -0 rm -f
(Mit z.B. PHP geht es auch, ist halt nur etwas aufwändiger…)
Wenn jetzt aber der Kunde kommt und irgendwas erzählt, dass das aber völlig betriebssystemunabhängig, "meinetwegen mit MsDOS" funktionieren soll, dann würde ich sagen "Er will es nicht schnell und günstig sondern langsam, aufwendig und kompliziert. Ab in die Datenbank mit dem Zeug! Viel Spaß mit MsDOS, dem Webserver, der Datenbank und der unabhängigen Skriptsprache!"
Falls der Kunde aber die Idee gut oder gut genug findet würde ich ihn darauf hinweisen, dass beim Backup mit rsync die Option "-H" gesetzt werden muss und dass natürlich niemand einen Artikel oder eine Nachricht anlegen darf, während die alten gelöscht werden. (Das kann man übrigens auch "programmtechnisch" sicherstellen.)
Übrigens:
Alle (harten) Links zu einem Bild (und damit die, mit einem Bild verbundenen Nachrichten) findet man bei dem vorstellten Prozedere extrem schnell mit:
find -inum $(ls -i image-dir/bild.png | cut -d " " -f1);