Looking at the Apple iPhone Core Data Recipes sample app, they store image files in core data objects, which is not something I would normally think would be wise. Now I’m going to be also storing captured video on the 3GS. The question is: is it wise to store images, and then furthermore, movies, in Core Data on the iPhone?
In addition there is the addition of loading into memory. Apparently the design used in Recipes (i.e., storing the image in a separate model) allows Core Data to do "faulting" (which sounds like it means lazy loading), but I’m not sure if that’s really true.
Looking here: http://developer.apple.com/iPhone/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPerformance.html#//apple_ref/doc/uid/TP40003468-SW5 it seems that the generic Cocoa advice is to use separate files….
It depends. CoreData is more than capable of storing large blobs with good performance. The big gotchas are:
If those blobs are properties of entities that might not always be faulted in you need to be careful to make sure whenever you use the entity you tell CD not to fault in properties until you ask. You can work around that by isolating the blobs in their own entities, which will not get faulted until you access it through the relationship.
Your persistent store is one monolithic file, which means if anything in it changes the whole thing needs to be copied during backups. This often increases the time it takes for the phone to backup while it is synching with iTunes, because you changed some metadata and now it has to copy every image.
The first issue is usually not a big deal, you just need to be careful. The second is not an issue if the data is effectively readonly, but if you have a couple hundred megabytes of data in your persistent store it can be a pretty awful user experience.