Bilder in Java-Webapplikationen

[kevin82]

Hallo,

ich würde gerne mal eure "best partices" erfahren. Wie speichert Ihr Bilder (die der Benutzer hochlädt) in euren Webapplikationen.

Lädt ihr die Bilddatei binär in die Datenbank, oder doch lieber im lokalen Filesystem?

Viele Grüße
Kevin

 

[Zireal]

Ich denke du wirst Gründe und Argumentationen zu beiden Apsekten finden. Ich persönlich würde es im Filesystem belassen. Ich habe das Gefühl die Bilder bleiben auf diese Weise "unverändert" und "original".

Nachteil ist natürlich, dass ein einfaches Datenbankbackup dann nicht genügt um die Bilder mitzusichern... Aber für dieses Problem lässt sich bestimmt eine Abhilfe schaffen.

Hast du denn bereits einen Ansatz, der für dich stimmt?


Zireal

 

[homer65]

Ich habe mal eine kleine Anwendung geschrieben, da werden Bilder als BLOB in der Datenbank gespeichert.
Meine Überlegung damals war, das nicht besonders viele Bilder abgespeichert werden und die Datenbank dadurch nicht sonderlich aufgebläht wurde. Von der Datenbank mache ich eh regelmäßige Sicherungen also brauchte ich mir kein neues Sicherungskonzept zu überlegen.

 

[Zireal]

Sind diese "Ich-denke-ich-habe-eh-nicht-so-viele-Daten"-Konstrukte nicht eher kritisch?

Allgemein sollte man meiner Meinung nach mit Lösungen arbeiten, die in jeder Situation einwandfrei funktionieren können. Unabhängig von Menge und Grösse der Datensätze.


Zireal

 

[maki]

Sind diese "Ich-denke-ich-habe-eh-nicht-so-viele-Daten"-Konstrukte nicht eher kritisch?

Das nennt sich UseCase bzw. Anforderung.

Allgemein sollte man meiner Meinung nach mit Lösungen arbeiten, die in jeder Situation einwandfrei funktionieren können. Unabhängig von Menge und Grösse der Datensätze.

Dann bleibt nur immer nur die DB Variante, man denke nur an Transaktionen, Datenkonsitenz,etc.
Kann ganz schön viel Aufwand sein (auch mit der HW/SW) wenn die Daten 2 bzw. 4 GiB überschreiten.

 

[Zireal]

Das nennt sich UseCase bzw. Anforderung.

Ich wollte viel mehr, auf die "Art" hinweisen Lösungen zu entwickeln, welche nur für diese eine Verwendung gebraucht werden können und sobald andere Aspekte dem "Use Case" beigefügt werden, nicht mehr in dieser Art und Weise verwendbar sind.

Dann bleibt nur immer nur die DB Variante, man denke nur an Transaktionen, Datenkonsitenz,etc.
Kann ganz schön viel Aufwand sein (auch mit der HW/SW) wenn die Daten 2 bzw. 4 GiB überschreiten.

Das stimmt. Doch der Aufwand würde sich vermutlich trotzdem ausbezahlen.

 

[maki]

Ich wollte viel mehr, auf die "Art" hinweisen Lösungen zu entwickeln, welche nur für diese eine Verwendung gebraucht werden können und sobald andere Aspekte dem "Use Case" beigefügt werden, nicht mehr in dieser Art und Weise verwendbar sind.

Beispiel:
Einen Elfenbeinturm zu bauen führt meistens dazu, dass der Kunde sagte: Wo ist die garage die ich bestellt hatte???

Man löst besser nicht alle möglichen Probleme/Anwendungsfälle die nicht gefordert sind, sonst wird man entweder nie fertig, oder im besten Falle hat man dann die berühmte "Overengienered/Overdesigned" Lösung.

Das stimmt. Doch der Aufwand würde sich vermutlich trotzdem ausbezahlen.

Nö, weil du einem Kunden eben nicht klarmachen kannst dass er eine teure, kommerzeille DB braucht um 100MB an Daten zu speichern.
Die OS DBs sind nicht so dolle wenn die Datenmengen richtig groß werden

Hab schon beides gemacht, das berühmte "kommt darauf an" stimmt immer wieder

 

[Zireal]

Beispiel:
Einen Elfenbeinturm zu bauen führt meistens dazu, dass der Kunde sagte: Wo ist die garage die ich bestellt hatte???

Man löst besser nicht alle möglichen Probleme/Anwendungsfälle die nicht gefordert sind, sonst wird man entweder nie fertig, oder im besten Falle hat man dann die berühmte "Overengienered/Overdesigned" Lösung.

Hihi, ich glaube wir reden aneinander vorbei.
Mein KuchenBeispiel:
Du möchtest einen Kuchen backen und da er eine ausgefallende Form haben soll, musst du eine Kuchenform basteln.
Bastelst du lieber eine Form aus einem einzigen Stück, dass du es für gerade diesen Kuchen verwenden und nur diese eine Form backen kannst oder baust du dir eine Form die aus ein paar Einzelteilen besteht, damit du X verschiedene Formen daraus zusammenstecken kannst und somit immer wieder Kuchen in verschiedensten Formen backen kannst?

(Abgesehen davon, dass wohl kaum jemand eine Kuchenform selbst "basteln" würde, geschweige denn in verschiedenen Formen - repräsentiert dieses Beispiel meine Aussage meiner Meinung nach treffend. )

Nö, weil du einem Kunden eben nicht klarmachen kannst dass er eine teure, kommerzeille DB braucht um 100MB an Daten zu speichern.
Die OS DBs sind nicht so dolle wenn die Datenmengen richtig groß werden

Hab schon beides gemacht, das berühmte "kommt darauf an" stimmt immer wieder

Nun gut, da muss ich dir Recht geben! Aber wenn du dem Kunden jedoch auch erzählen würdest, dass er damit auch mehrere Gigabyte an Daten aus zukünftigen Projekten sichern könnte, sieht das ganze vielleicht anders aus? Vielleicht. Investition?

 

[homer65]

Allgemein sollte man meiner Meinung nach mit Lösungen arbeiten, die in jeder Situation einwandfrei funktionieren können. Unabhängig von Menge und Grösse der Datensätze.

Reines Wunschdenken. Wäre tatsächlich schön, wenn man das könnte. Aber man kann eben nicht.

 

[Zireal]

Reines Wunschdenken. Wäre tatsächlich schön, wenn man das könnte. Aber man kann eben nicht.

Klar! Jedoch kann man sich an solche Lösungen "herantasten" in dem man entsprechende Technologien verwendet.

 

[homer65]

Klar! Jedoch kann man sich an solche Lösungen "herantasten" in dem man entsprechende Technologien verwendet.

Hmh, das ganze fängt schon bei der Hardware an, die man einsetzt. Die muß zu den Anforderungen passen.
Dann geht es bei der Architektur der Software weiter. Die legt man für große Datenmengen und viel Durchsatz auch anders an.
Jedenfalls erfordert so eine Lösung erheblich mehr Aufwand und wird damit auch entsprechend teuer.

Was spricht dagegen für einen einfachen Anwendungsfall auch eine kostengünstige Lösung zu suchen. Man macht nur das was nötig ist.

Das Beispiel mit der Garage und dem Elfenbeiturm finde ich gut. Vielleicht wäre der Kunde auch mit dem Elfenbeinturm zufrieden, wenn er ihn zum Preis der Garage bekäme.

 

[maki]

Aber wenn du dem Kunden jedoch auch erzählen würdest, dass er damit auch mehrere Gigabyte an Daten aus zukünftigen Projekten sichern könnte, sieht das ganze vielleicht anders aus? Vielleicht. Investition?

Klar, wenn er einsieht dass es zwischen 300% und 3000% teurer ist und ihm "heute" aber keinen Vorteil bringt

Das ist leidier viel zu oft passiert, aber ohne dass der Kunde eine Wahl hatte, man sehe sich alte J2EE Projekte an..
Theoretisch: Skalierbar , Clusterfähig, ausfallsicher, standardkonform
Praktisch: sehr teuer, nicht skalierbar/Clusterfähig weil man sich nicht an den Standard gehalten hat, viel komplexer als notwendig

Es ist wirklich so, dass man am flexibelsten (und kostengünstigsten) bleibt, wenn man nur die genau die Problem löst bzw. Anforderungen umsetzt die der Kunde hat.

 

[Zireal]

Klar, wenn er einsieht dass es zwischen 300% und 3000% teurer ist und ihm "heute" aber keinen Vorteil bringt

Das ist leidier viel zu oft passiert, aber ohne dass der Kunde eine Wahl hatte, man sehe sich alte J2EE Projekte an..
Theoretisch: Skalierbar , Clusterfähig, ausfallsicher, standardkonform
Praktisch: sehr teuer, nicht skalierbar/Clusterfähig weil man sich nicht an den Standard gehalten hat, viel komplexer als notwendig

Es ist wirklich so, dass man am flexibelsten (und kostengünstigsten) bleibt, wenn man nur die genau die Problem löst bzw. Anforderungen umsetzt die der Kunde hat.

Vermutlich hast du Recht. Doch es gibt bestimmt Leute welche für solche Projekte eine Investition als lohnenswert erachten. (Da es Ihnen in Zukunft Vorteile einbringen kann...)

Nun gut, wir sind etwas vom Thema abgewichen.