I'm designing an iPad/iPhone app using core data. The main focus of the app is sorting and viewing up to 20,000 PDFs They are ~200KB each. Typically its best to not store BLOBS in a DB, but for desktop systems I've typically seen it said that if the blobs are < 1 MB then its fine to use the DB. Any considerations I should take into count? If I store them in the file system can I store them all in one directory and not have performance issues (I won't need to ever get a directory list since I'd store each's path in the DB)? Should I divide them among a handful of directories? If so is there a good rule on # of files per dir?
+5
A:
I would go for paths inside your database. It's faster, by lookup and for backup reasons. I personally use a relative path to a directory, so I can change the "root" folder in case of system migration or load balancing. You can store them in a single directory, because when you are looking them up from your database, it's by unique id (if your schema is designed that way).
You can store easily 1 meg BLOB's inside SQLite (other databases too). Just wouldn't recommend it.
Shyam
2010-04-08 00:10:09
Core Data (generally) uses SQLite as a backend, not MySQL.
Shaggy Frog
2010-04-08 00:13:20
Excelent point. I had forgotten about backup. The database data does need to be backed up but the PDFs don't since the app can always redownload them as needed.
jamone
2010-04-08 00:20:51