On Tue, Apr 19, 2005 at 01:20:35PM -0500, Kurt Welgehausen wrote: > SQLite is not a client-server database.
Yup. I realize that. > In the worst case, when you query a database file over NFS, all the tables in > your query are sent over the network to be processed on your cpu; so if you > want to select one row from a table of a million rows, the million rows are > retrieved over the network (in the worst case). Which is where presumably SQLite's page caching would come in... At least for subsequent queries on the same table. > You may want to consider a client-server database for this reason and also > because there have been reports that locking does not work reliably on some > implementations of NFS -- so you could be risking a corrupted db file if you > have multiple users. We definitely do NOT want a client-server database. As I noted, SQLite is being used to store, in effect, an application's "save files". The fact that SQLite stores its databases as a single, user movable, file is one of the key features that makes it of interest to us. Multiple users will also be a rarity (if it EVER occurs). What SQLite is giving us is the ability to mainpulate a large (gigabyte sized) file containing complex structures, without having to do all the "dirty work" (indexing, endian-ness translation, caching, etc.) ourselves. > I think this has been discussed on the list. You could try a search of the > archive: > > <http://www.mail-archive.com/[email protected]/> I did. Almost all of the posts seemed to relate to the correctness of the NFS locking and how it could be improved. I really don't care so much about correct locking for our application. I'm more worried about the performance. -- William Hachfeld
