Datenbank für kleine Thumbnails?
-
zwutz schrieb:
Warum?
warum sollte es denn sinnvoll sein?
es bläht die datenbank nur auf und du kannst sowieso keine sinnvollen operationen auf die rohen bilddaten anwenden.
du bremst im prinzip nur deine datenbank damit...
-
Shade Of Mine schrieb:
zwutz schrieb:
Warum?
warum sollte es denn sinnvoll sein?
es bläht die datenbank nur auf und du kannst sowieso keine sinnvollen operationen auf die rohen bilddaten anwenden.
du bremst im prinzip nur deine datenbank damit...
jep... auserdem kann dir durch ein missgeschick passieren das deien binär daten irgendwie verwurschtelt werden ^^ ...
-
Shade Of Mine schrieb:
zwutz schrieb:
Warum?
warum sollte es denn sinnvoll sein?
es bläht die datenbank nur auf und du kannst sowieso keine sinnvollen operationen auf die rohen bilddaten anwenden.
du bremst im prinzip nur deine datenbank damit...
schon klar, aber was ist die Alternative, wenn die Bilder einfach dazugehören? Auf dem Dateisystem ablegen und den Pfad in der DB speichern? Was ist, wenn der Pfad sich ändert, wenn die DB umzieht oder der der Pfad anderweitig ungültig ist? Man kann sich so nie drauf verlassen, dass die Daten da sind, wo man sie erwartet.
Ich will hier keine Herangehensweise favorisieren... nicht umsonst hab ich vor gut nem Jahr hier nen entsprechenden Artikelvorschlag gemacht, der eben solche Fragen klären sollte... ich selber wüsste nicht, wo ich die Bilder speichern soll und das obwohl ich in der Datenbanktheorie zumindest nicht unbewandert bin
-
zwutz schrieb:
Man kann sich so nie drauf verlassen, dass die Daten da sind, wo man sie erwartet.
relative pfade.
das bedeutet zB auch dass du die bilder lokal am webserver speichern kannst während der db server nur übers langsame netzwerkverbindungen erreichbar ist.
-
Shade Of Mine schrieb:
das bedeutet zB auch dass du die bilder lokal am webserver speichern kannst während der db server nur übers langsame netzwerkverbindungen erreichbar ist.
ok, der Punkt leuchtet ein
ich beziehe meine Zweifel großteils aus diesem Thread. Da kam in etwa die selbe Frage auf.
Dort wurde aber eher das Ablegen in der DB favorisiert
-
Naja, einige RDMBSysteme gehen ja den Weg dass sie genau das automatisch machen was wir hier sagen:
nämlich blobs ins dateisystem zu speichern und in der datenbank nur noch eine referenz id zu halten.wenn deine db das so macht, kannst du die daten natürlich auch in der datenbank speichern (da es dann ja keinen relevantn unterschied zu direkt am filesystem speichern hat).
ich persönlich mag es dennoch nicht - aber der wichtigste punkt ist, dass binär daten in einer datenbank die db ausbremsen. solange das aber nicht der fall ist, ist es ok.
hängt auch stark von der struktur ab. wenn du zB webserver hast und dahinter db server, dann ist es vermutlich klüger die daten auf dem webserver zu legen.
wenn du aber ein db system mit unterschiedlichen clients hast die sich zB direkt zur db verbinden, ist es uU sinnvoller die daten in die db zu legen und uU einen lokalen cache am client zu halten...
-
Naja, mittlerweile finde ich die Idee, die Daten in Blobs zu quetschen, nicht mehr wirklich gut.
Dateisystem wird wohl in meinem Falle das sinnvollste sein...
-
Wenn Du MSSQL 2008 nimmst dann kannst Du die Bilder in der DB ablegen. Neuer Spaltentyp und Filestream.
Ist sehr schnell und Repliziert auch.
Dadurch keine Probleme wenn die DB umzieht, man kann Select vom Replikat machen etc.
-
Da das wohl eher die absolute Ausnahme ist, das man sich auf einem MS Server rumquälen muss ist das etwas "Exotisch".
Und schon allein deswegen würde ich es niemals zum 'Standard' machen wollen.
-
Abgesehen davon das DU nichts zum Standard machen kannst ist Filestream auch nicht für Hobbyprogrammierer gedacht.
Bei Filestream geht es um etwas mehr als Bin-Daten in der DB abzulegen ohne Blob zu verwenden.
Stichwörter sind: Cluster, Replikation, Datensicherung, Datenumzug, Serverfarmen, etc.
-
Nö, weder Du noch ich legen Standards fest.
Nur für diesen expliziten Fall ist das Thema was du ansprichst auch als etwas
oversized anzusehen.
Es hat sich ein 'Standard' aus der Vernunft gebildet, das rohe Bilddaten nichts in einer DB zu suchen haben.