0

this question has been asked many times, I have read many users telling that it is not advisable to store images in a DB, in particular within CoreData. By they all seems to omit the reason why they would do so. Even Apple documentation state this, and everybody points to that direction, and every discussion end like this "well you can, but storing the path is better".

Apart from opinions, I would like to have a concrete example of why it is not a good solution.

I explain better, I have a strong background in building Web Application. A concrete example I would give from my point of view could be: do not store images in a DB, but rather the path to them, because you can have them served them by the web server, which can apply all of its caching issues.

But in a desktop environment, especially in iOS application, what are the downside of having stored in Core Data using sqllite, providing that:

There's a separate entity holding the images, it is not an attribute of main entity

Also seems to be a limit of 100kb for images. Why ? What does happen with a 110,120...200kb ecc ?

thanks

Leonardo
  • 9,607
  • 17
  • 49
  • 89

3 Answers3

4

There's nothing special about what Core Data normally does here. It's just using an SQLite database. You can put large blobs of data into it, but it just doesn't scale all that well. You can read more about it here: Internal Versus External BLOBs in SQLite.

That said, Core Data has support for external blobs which in Core Data terminology is called stored in external record (iOS 5.0 and later). Again, there's nothing magic about it, it's just storing the large pieces of data in the file system separately from the SQLite db itself. The benefit is that Core Data updates all this for you.

When you're in Xcode, there'll be a checkbox called Allows External Storage that you can check for Binary Data properties.

Daniel Eggert
  • 6,665
  • 2
  • 25
  • 41
1

The filesystem, and the API:s surrounding it is (just like a webserver) optimized to serve files, of any size, and to apply caching where appropriate.

CoreData is optimized for handling an object graph with tiny pieces of data, like integers and short strings.

Also, there are a number of other issues that tend to creep up on you, like periodically vacuuming the SQLite database CoreData uses, or it won't be able to shrink, just grow.

geon
  • 8,128
  • 3
  • 34
  • 41
  • 1
    It's not entirely true that you periodically have to vacuum the SQLite database. You can specify a `PRAGMA auto_vacuum` and set it to either `FULL` or `INCREMENTAL` to avoid this. More in the [SQLite documentation](http://www.sqlite.org/pragma.html#pragma_auto_vacuum). – Daniel Eggert Jun 02 '12 at 08:19
0

Leonardo,

With Lion/iOS 5, Core Data started handling file system storage of large BLOBs for you.

The choice is really determined by how many images you are going to have open. If you have many, then you should keep them in the DB. Why? Because you only have a modest number of file descriptors, one of which is used for each open image stored in the file system.

That said, there is still a reason to manage the files yourself. If your BLOBs are really big, say 2+ MB, you will want to map them into memory and not just read them in. (When the memory warnings come, this lets the OS automatically purge them from your resident memory. This is a very good thing.) Even so, you still have the limited number of file descriptors problem.

Andrew

adonoho
  • 4,339
  • 1
  • 18
  • 22