5

im wondering if storing images as BLOB in the sqlite database would be a good idea? Does anybody has performance - experience with storing images (blob).

My android app would be a small one, which will need to handle 20 to 100 images (100 kb up to 1MB per image). Worst case: I would say, that my database could reach a size of 100 MB. Does this has significant impact on the database performance? Average case: I guess the average user of my app has 40 images with 200 kb per image, so the size of database would be around 8 MB. Btw. of course the database stores also other "normal" data, so its not a image database only :)

Is storing the path to the image which is stored on the storage(internal or sd card) a better approach? I guess that retrieving the image file path from the database and open and load the image from file would be a little bit slower (but not really significant, since I need to load only two images at once).

A second question: If I would use the second approach (store the path to image file in the database and load the image file): Does a disk cache (DiskLruCache) is something useful in this scenario? Would it bring a significant performance boost? My understanding is that a Disk cache would store bitmaps (instead of encoded jpg or png) and therefore a disc cache would load a bitmap directly from storeage and my app would save the time to decode the image(jpg or png). Is that correct? Btw. In the "database approach" i would store the image already decoded as bitmap. So it seems to me to be something similar as the disc cache, isnt it?

Edit: I forgot to tell you, that i need to store the images persistent on the device. Im not talking about caching images that for example I have retrieved from a web service ...

sockeqwe
  • 15,574
  • 24
  • 88
  • 144
  • Why not save the images to cache folder ? – Tomer Mor Jan 01 '13 at 13:06
  • 1. The user can clear the cache in the Androids App Settings. 2. Saving an Image in the cache folder would have the same performance as saving the file in any other folder, isnt it? 3. I like the concept of transaction that i could use by storing the image in the database – sockeqwe Jan 01 '13 at 13:10
  • you can save to which folder you like or to the external storage, for more information read http://developer.android.com/guide/topics/data/data-storage.html it's not recommended to save images to D.B. – Tomer Mor Jan 01 '13 at 13:15

1 Answers1

3

My guess will be that the database will get significantly slower if you store that much of information in it, especially when you retrieve the images themselves.

On the other hand, as I get it, every user has the images associated with him downloaded after the application is installed. This is perfect place for using a library another SO user recommended to me in a question of mine I asked couple of days ago: Universal Image Downloader. Here is a link to the thread I speak about.

This library uses on disk caching, but abstracts away all the complexities for you (hopefully, I have not yet tried it, but it seems promising).

Community
  • 1
  • 1
Boris Strandjev
  • 46,145
  • 15
  • 108
  • 135
  • The universal Image Downloader looks very interesting and promising. Thank you for the hint! In fact i planed to implement something similar for my app (especially displaying an "empty" image while loading the real one), but i guess I will try this library first. However before i continue it would be nice to know if the database approach is not better for my app – sockeqwe Jan 01 '13 at 13:27
  • @sockeqwe I think I covered that in my answer, but once more: everything in the database will have performance issues, you will have to implement a lot more custom logic on your own. Basically I have the observation that in android the database performs a lot worse than ordinary file system in some cases (especially when reading large chunks of data). Furthermore UID has niceties like saying how much at most must be cached etc – Boris Strandjev Jan 01 '13 at 13:31