Dateien im Asset Ordner anlegen

[Tom299]

reiti.net meinte, die bilder gehören in die DB ;-)

und spike78 wollte ja zuerst nen mix machen, also seine original in den assets() und die neuen / geänderten dann auf sd karte. und da ist es doch einfacher, daß man alle bilder an einer stelle hat und nicht verteilt

 

[swordi]

Bei einer DB will man aber nunmal keine Dateninkonsistenzen Was also, wenn der Benutzer die SDKarte entfernt, oder das Bild löscht?

Wäre also defintiv sinnvoll, die Bilder selbst in die DB abzulegen mit der Möglichkeit, dass der Benutzer von einer SDKarte importieren kann.

So funktioniert die ganze App dann übrigens auch ganz ohne SDCard.

gar nicht gut!

wenn du 20kb bilder hast dann super, aber im normalfall sind bilder etwas größer und dann viel spaß wenn das alles im internen speicher liegt.

wenn du die bilder schon in den internen speicher legst, dann reicht es wenn du in der db eine referenz mit dem bild namen hast. das ganze bild ( blob ) hat in der db, meiner meinung nach, nichts verloren.

android hat leider (noch immer) sehr wenig internen speicher und somit musst soviel wie möglich auf die sd karte auslagern.

 

[Reiti]

Wie gesagt, Daten die zusammen gehören sollten auch zusammen bleiben (das gilt für alle Daten) - die Sache mit dem begrenzten Speicher auf dem Smartphone ist natürlich ein Argument, das man gesondert betrachten muss: zB benötigt man die Bilder in voller Auflösung etc - das geht so glaube ich aus dem bisherigen Thread nicht hervor.

Alternativ ist natürlich einfach den vollen Bildpfad in die DB mit abzulegen und ggf. darauf zu achten, dass diese Daten auch mal fehlen können.

Wenn man möchte kann man sich auch ein Flag mitspeichern ob das entsprechende Bild im asset folder ist oder nicht .. immer gemäß dem Falle, das eine SDCard schlichtweg einfach fehlen kann.

 

[mradlmaier]

Bei einer DB will man aber nunmal keine Dateninkonsistenzen Was also, wenn der Benutzer die SDKarte entfernt, oder das Bild löscht?

Wäre also defintiv sinnvoll, die Bilder selbst in die DB abzulegen mit der Möglichkeit, dass der Benutzer von einer SDKarte importieren kann.

So funktioniert die ganze App dann übrigens auch ganz ohne SDCard.

Gutes Argument. Binäre Daten in die db ist möglicherweise einen satten Performance Hit.
Würde das erstmal testen, wie da sqllite performt, vor allen auf den etwas schwächeren Smartphones. Schreibzugriff ist ja eher selten... und wenn der Lesezugriff einigermassen schnell funzt...
Dateikonsistenz und Unabhängigkeit von der SD wäre mir schon wichtig. Wenn das einigermassen schnell funktioniert, würde ich das so machen.

 

[Reiti]

Sollte die DB nicht jucken - blobs liegen eh getrennt (wie "text"-typ-spalten) - der einzige Performance Punkt ist, dass die ganzen binären Daten über die DB Connection fließen müssen da hinter android aber linux liegt und damit ne pipe genutzt wird ist das quasi egal.

Vielleicht aufpassen, dass man beim select nicht mit den binärdaten joint - ich weiß nicht ob sqlite entsprechend nur 1x referenziert (sollte aber).

Tipp (für android eher unerheblich) arbeitet man mit sehr sehr vielen Dateien, dann ist die DB sogar schneller (db ist schneller als dateistruktur durchsuchen)

 

[mradlmaier]

Sollte die DB nicht jucken - blobs liegen eh getrennt (wie "text"-typ-spalten) - der einzige Performance Punkt ist, dass die ganzen binären Daten über die DB Connection fließen müssen da hinter android aber linux liegt und damit ne pipe genutzt wird ist das quasi egal.

Vielleicht aufpassen, dass man beim select nicht mit den binärdaten joint - ich weiß nicht ob sqlite entsprechend nur 1x referenziert (sollte aber).

Tipp (für android eher unerheblich) arbeitet man mit sehr sehr vielen Dateien, dann ist die DB sogar schneller (db ist schneller als dateistruktur durchsuchen)

Ich habe mal gelesen, dass sqllite intern nur mit einem Datentyp, String, arbeitet, auch für zahlen und datum? Wie handelz sqllite dann die blobs?

 

[Reiti]

Es ist uninteressant - weil die DB über Indizes sucht und referenziert - die DB greift die blobs ja gar nicht an im normalen Betrieb. Und wenn doch, dann ist es ja ein fester Zielzugriff.

Auch sqlite arbeitet lieber mit Zahlen ;-)

 

[swordi]

ich sag mal so

eine datenbank ist eine DATENbank und keine BILDbank.

wenn es ein paar kleine bildchen sind, dann von mir aus. ich mags nicht, aber anderen anscheinend sehr.

wenn es größere dateien sind, wird die datenbank das nicht gerne haben.

so als kleines beispiel:
wir haben eine listview, jede zeile enthält ein bildchen und text.
jetzt laden wir die daten aus der datenbank - sagen wir mal 100-200 einträge.

hmm cool jetzt haben wir entweder
1) alle bildchen im speicher
2) müssen die bilder bei bedarf erst aus der db laden.

ein db zugriff ist ganz sicher nicht billiger als ein filezugriff.

1) zeile wird am bildschirm angezeigt
2) getView wird ausgeführt
3) db öffnen
4) query absetzen
5) result parsen
6) db schließen
7) bild setzen
8) liste aktualisieren

sind schon viele schritte, die in jeder zeile durchgeführt werden müssen.

 

[Reiti]

Für die Datenbank ist es aber irrelevant ob es sich bei Daten um Text oder ein Bild handelt (sie weiß es nichtmal). Dafür hat sie ja Indizes und auch nur da ist eine DB effektiv.

Du würdest das Bild aus der DB nicht öfter oder weniger laden als vom Filesystem insofern gibt's quasi auch nicht mehr overhead. Wenn es sich um viele Bilder handelt wäre es ja genauso ineffizient sie jedesmal von der Platte/SD zu laden. Die DB ist ja auch nur eine "Datei" und nur die Indizes liegen im Speicher (vom caching mal abgesehen).

Auch braucht man ja nicht immer das ganze Bild, für die Listview würde ein Thumbnail ausreichen, die könnte man extra in der DB speichern, man muss sich nicht um doppelte Dateinamen kümmern sondern hat AutoIncr, kann selbst per key cachen usw.

Und ein DB Zugriff IST billiger als ein FileZugriff - denn die DB kann effektiver "suchen", was sie nichtmal muss, wenn bereits der richtige Key vom Query kommt (den man ohnehin ausführen muss.. Tatsächlich macht das aber auch erst bei Servern einen merkbaren Unterschied.

Wie gesagt rein technisch ist es für die DB vollkommen egal ob die binären Daten durch einen (teuren) fopen außerhalb der db kommen oder die db die daten von einer bekannten position (index) in einer bereits geöffneten datei (der db) kommen.

Man könnte jetzt mehr ins detail gehen und anmerken, dass ein dateiname "/.../.../..." (den man in der db speichert) schnell mal 80 byte extra daten sind .. und bei 100 bildern wären das schon fast 10kB nicht benötigter speicherverlust ..

Aber bleiben wir real - auf einem smartphone mit 1 aktivem User ist es performance-technisch ziemlich egal ob man auf DB oder FS zugreift - da kommt es eher auf das programm selbst an, was es mit den Daten macht. So bleiben die anderen Punkte, wie zb die unabhängigkeit von SDCard usw

 

[swordi]

hmm kann es sein dass du sqlite mit MS SQL oder Oracle verwechselst ? da liegen aber welten dazwischen.

aber egal: ich werd auch in zukunft keine bilder in die db packen. wenn du damit gut fährst, ist das natürlich ganz ok...

 

[Reiti]

nein, verwechseln nicht, mysql und oracle haben ganz andere dinge drauf ;-) BLOBs sind aber ne ganz einfache geschichte .. nichts anderes als TEXT spalten (nicht verwechseln mit VARCHAR!).

Dazusagen muss man jetzt aber auch, dass man mit Blobs schon aufpassen muss und wissen, was man tut. ein select join alles ist dann natürlich ein fail ;-)

 

[Tom299]

ich habe mal gelernt, daß man bilder oder auch videos, etc. NICHT in der DB speichert und das ist auch gut so.

man hinterlegt den pfad in der DB und NATÜRLICH MUSS MAN IMMER beim laden überprüfen, ob der pfad existiert. fehlerhandling gehört nun mal zum standard dazu. und gerade bei bilder kann man ja auch ein "default"-bild oder platzhalter anzeigen, wenn der pfad nicht mehr existiert (z.b. aus dem assets-ordner).

also ich bin der gleichen meinung wie swordi, bilder gehören nicht in die DB. aber letztendlich kann jeder so machen wie er will ;-)

 

[DieGoldeneMitte]

Datenbanken für Bilder and andere nicht inhaltlich such/indexierbare Daten sind Filesysteme.
Es steht jedem frei, in sqlite ein Filesystem zu bauen.
Mag sogar Situationen geben, in denen das sinnvoll ist.
Ich ziehe es aber (wie swordi) vor, das Rad nicht neu zu erfinden

 

[Tom299]

angenommen, man speichert bilder in der DB. kann man dann auch nach name, dateiendung, erstellungsdatum, dateigröße sortieren? oder muß man dafür zusätzliche spalten in der db anlegen?

 

[Reiti]

@Tom Diese Halbwahrheit lehrt man in Access kursen. Es ist rein technisch für die Datenbank ziemlich irrelevant - rein praktisch kann man aber dabei viel falsch machen, wenn man nicht weiß, wie die Datenbank intern funktioniert (Selects, joins, fragmentierung etc).

Ich sage ja nicht, dass man grundsätzlich Bin-Daten in eine Datenbank schreiben soll, für den obigen Anwendungsfall ist es aber sinnvoll - WENN(!) man dann auch weiß was man tut und nur dann! Dieselben Fehler machen Leute mit TEXT Spalten (ohne es zu wissen) weil es grundsätzlich nicht sooo böse ist TEXT Spalten zu benutzen (obwohls dasselbe is)

@GoldeneMitte
SELECT data FROM images WHERE id=1
oder
new File('/bla/bla2/bla3/bl4.bmp')... etc

beides liefert einen stream, der gelesen werden kann. probier das mal aus du wirst staunen, wieviel schneller die DB das kann.

@Tom Zu Deinem Verständnis: Wenn wir hier von Bildern in der DB sprechen, dann handelt es sich dabei um eine BINARY Spalte (ein blob) - da gibt es keine datei es gibt nur gespeicherte Daten (in diesem Fall der Fileinhalt) aber kein File mehr.

Man kann einfach nicht sagen "ja BINARY in DB ist böse" wenn man nicht weiß warum und die Vor- und Nachteile nicht kennt. Weder baut man sich ein Filesystem nach - noch bremst es die DB aus (ein falsches SELECT bremst die DB aus).

In der Entwicklung von Software geht es immer um die effizienteste Lösung mit Bedacht auf den Einsatzzweck einer Applikation.
In obigen Falle ist es am vernünftigsten die Daten in die DB zu legen (die immer da ist) als auf einem FS das eventuell fehlen (oder gewechselt) werden kann (da stimmt ihr mir hoffentlich zu).
Damit man diesen Weg gehen kann sollte man schon einiges Wissen über Datenbanken haben - damit erreicht man dann in versch. Szenarien auch eine erheblich bessere Performance.

Apropos - und damit zurück zum Thema: Ist ja schön, dass man Fehlerhandling macht .. aber was soll die App machen, wenn die SDKarte mit den Bildern entfernt wird .. Fehlerbild anzeigen, Referenzen entfernen? Was, wenn die SDKarte wieder eingesetzt wird, thumbnailhandling .. usw usw .. Es ist für eine App nunmal problematisch, wenn man nötige oder verknüpfte Daten entfernt - abfangen ist eine Sache, aber wie behandeln.

 

[Tom299]

also ich habe nie einen access-kurs gehabt, aber vor ca. 11 jahren mein informatik-studium beendet und da hab ich sowas gelernt. mag sein, daß es heute anders gelehrt wird, aber ich glaubs nicht ;-)

und meine fragen waren eher als kritikpunkte gedacht, weil mir ist schon klar, was ein blob ist

das einzige, was ich jetzt NICHT weiß: wenn ich ein bild in der DB speichere, wird es gepackt oder hat es die gleiche größe wie auf dem filesystem, oder gar noch etwas mehr? ansonsten würde es ja keinen unterschied machen, ob ich es INTERN oder in der DB ablege, die größe wäre immer die gleiche. die DB würde ja dann genauso wachsen wie das filesystem. und wenn ich speicherprobleme hätte, dann würde es nur mit der SD karte funktionieren. ich vernachlässige jetzt mal die performance, geht nur um die speicherverwaltung

und btw. der entwickler ist immer für das fehlerhandling verwantwortlich. zur not kannste auch knallhart sagen, wenn die app startet und keine SD karte findet, dann wird die app wieder mit entsprechendem hinweis beendet. ist natürlich nicht gerade benutzerfreundlich, aber auch eine mögliche methode ;-)

 

[Reiti]

ich hab's nicht böse gemeint

Die DB speichert genau das was du ihr zu speichern gibst, wenn es der Fileinhalt ist, dann ist es der Fileinhalt - wie gesagt, die DB hat keine Ahnung WAS du ihr gibst - für die sind das nur ein Haufen Bits (Datenstrom) die per Key zugreifbar sind.

Der User kann halt nicht einfach eine Datei löschen um Speicherplatz freizugeben - da muss der Entwickler schon entscheiden und Vorsorge treffen, je nachdem was für die App wichtiger ist. 1000 8MB Bilder in der DB haben natürlich sehr großen Streitwert, keine Frage .. da muss man schon dran denken und entscheiden wie sinnvoll es ist.

Autsch - also ich mag keine Apps die gleich gar nicht starten, nur weil ein kleines extra-feature eine sdcard benötigt

 

[Tom299]

ich habs auch nicht böse gemeint, ich diskutiere aber bei interessanten themen gerne. außerdem lern ich dann ja auch meist noch was dabei

und ja, ich würde die app auch nicht einfach wieder beenden, war ja nur die möglichkeit, die ein böser entwickler haben könnte ;-)

 

[swordi]

bei android ist das aber zu 95% nicht gut, da interner speicher begrenzt. das fällt hier in der diskussion komplett flach.

da kann die db 100 mal besser sein, wenn der user die app nicht installieren will, da sie den begrenzten internen speicher zumüllt.

das ist leider sehr wichtig bei der entwicklung. da seh ich lieber ein dummy bild, wenn ich meine sd karte entfernt hab.

 

[DieGoldeneMitte]

Jau, solche Diskussionen sind immer wieder interessant.

• Man sollte bedenken, dass ein SelectStatement mehr macht als ein new File().
• Ein Haufen Bits schnell aus der Datenbank geholt sind noch keine Resource, die ein Android grafisch darstellt (ja, es ist nicht schwer, eine draus zu machen).
• Davon abgesehen: ich hoffe, das niemand auf die Idee kommt, mit DBs die drawable-XYZ nachzubilden.