9

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?

jamone
  • 17,253
  • 17
  • 63
  • 98

1 Answers1

9

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
  • 2,357
  • 8
  • 32
  • 44
  • 2
    Core Data (generally) uses SQLite as a backend, not MySQL. – Shaggy Frog Apr 08 '10 at 00:13
  • 2
    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 Apr 08 '10 at 00:20