Thanks Simon, > SQLite can certainly return more than 3000 records without problems. But I'm > not sure why you're asking about SQLite but talking about .jpeg files. A > file is a file. It lives in a directory on a disk, not in a database. If > you want to keep picture information in a database, it's just another BLOB > field, not a file at all. > I am sorry, That was a mistake. Actually my DB is dealing with jpeg and avchd files. I meant "data"
CE means Consumer Electronic :-) Regards, Sen On 4/12/2010 3:59 PM, Simon Slavin wrote: > On 12 Apr 2010, at 10:58am, Navaneeth Sen B wrote: > > >> Currently I am working in a project where we are developing a CE >> product, which is using a DB which was developed by one of our teams. >> I am facing some of the below mentioned issues with the current DB: >> >> * Listing of more than 3000 .jpeg files will produce a system hang >> > > >> * Cannot simultaneously update and list the contents in the table >> * Sorting can be done only by using a maximum of two fields >> > These two are not problems, depending on how 'simultaneous' you want to be > (milliseconds ?). SQLite handles multi-user locking if your CE platform and > operating system does. By the way, I don't know what 'CE' means. > > >> [snip] >> >> I would also like to know how SQLite stores AVCHD files in the DB. >> As you know AVCHD files have a peculiar directory structure(association >> with .cpi files), how is it handled in SQLite? >> > Same comment as about the .jpeg files: it doesn't, and nor does any other SQL > database system. No database system stores files. That's what a file system > does. A database could store the bytes that made up a file, but as you point > out AVCHD 'files' are not files at all, they're collections of files > (directories, but more like 'bundles' if you're used to Mac OS X), so you'd > need to invent a convention for explaining which bytes came from which file. > > I think you need to decide how you want to handle these files. Either keep > the files on disk and just store the path/filename in a database field (in > which case they're just short text fields and trivial to handle) or read the > bytes out of the files and store them in BLOB fields (which will take a lot > of programming and your database will be huge). Either way, the database is > still not storing a file, it's storing text or a BLOB. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
