On Wed, Jun 16, 2010 at 10:04 AM, Teg <t...@djii.com> wrote: > Hello Sam, > > I store multiple gigs of image files, some as large as 2-3 megs in > Sqlite DB's. For pretty much the same reason, the convenience of > having them in one package. For my requirements, extracting the images > from the DB, and displaying them isn't a bottleneck. It's fast enough. > > Search speed was improved by not storing the meta-data in the same > table as the blob data. If I wanted to improve performance even more, I'd > keep the meta-data in a different DB file. Essentially a DB for blobs > and a DB for meta-data. It seems that seeking over the blobs to get to > the meta-data in the combined DB is somewhat slow.
Teg, Thank you for the info! I had always intended to store the metadata in a separate DB then the blobs. There will always only be one metatdata DB, the only question is whether there is one big blob DB or multiple blob DB's which are broken into logical groupings. The system already has the concept of groups the images, so conceptually the later is very logical. Of course the advantage to one big blob DB is not having to figure out which DB to open to get the images. A few customers will load upwards of 100,000 to 150,000 images in one events. How well does SQLite handle large blob DB's? There are two images that I want to store, a thumbnail (4K~8K) and a large image (80K~160K). That would result in one DB between 9Gig and 25Gig. Now that I do the math, breaking them into logical groups that normally don't have more then 2000 images and normally only a few hundred, seems like a much more practical approach;) Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
