On Wed, Jun 16, 2010 at 8:34 AM, P Kishor <punk.k...@gmail.com> wrote: > On Wed, Jun 16, 2010 at 7:23 AM, Andreas Henningsson > <andreas.hennings...@gmail.com> wrote: >> Do some testing to find out if it suits the application you develop. >> But just in general .. file systems are build to handle files, databases are >> for handle data. >> > > Well, at the risk of being pedantic, you say files I say data (sung to > the tune of "you say poe-tay-toe, I say poe-tah-toe").
I am in total agreement ;) > But yes, my sense is (no firm, scientific tests backing this claim, > mind you), that storing very large binary objects in a db doesn't seem > efficient. Storing them on the file system while storing their > metadata in the db seems a lot more efficient. On the other hand, a > case could be made for storing blobs in the db when you have many, > many small binary objects, as in the case of image thumbnails. > Especially if the blobs are smaller than a page size, the db would > likely be extremely efficient. A lot also has to do with the requirements: My software is an event image viewing system, where each event is seen as a single "document" and all the data associated with the "document" is contained within the "event" folder. Currently only the metadata is stored in the database, all the images are stored in folders that are within the "event" folder. I am guessing, as is others, that storing the large images in the SQLite DB would be less efficient then how I am storing it now. One side effect, though is the requirement to backup the "event" folder. It takes a LOT longer to copy 5000 4k~8k files then it would be to copy one 20M ~ 40M database file. Because of this, in time I want to move all the thumbnails into one SQLite file, or maybe have one SQLite file per current folder holding images. Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
