On Sun, Apr 23, 2006 at 07:30:21AM +1000, John Stanton wrote: > I have actually done that and it works well for a particular class of > applications, ones with a relatively small number of simultaneous users. > For large numbers we switch to PostgreSQL The basic architecture of > Sqlite, and why it is "Lite", is that it uses a single file and file > locks for synchronization. That is very well adapted to myriads of > applications, but does not make it a competitor to DB2, Oracle or > PostgreSQL in the enterprise area. The single file makes it a dream to > maintain, but there is a price involved for that simplicity. > > Dr Hipp put it succinctly when he pointed out that Sqlite is a > replacement for fopen(), not Oracle. > > In our server we do not rely on the file locks in Sqlite but instead > serialize the transactions using the mutex/condition/event capabilities > which become available in such a framework. > > As for your idea of pluggable storage methods, I consider that a better > approach for an embedded tool like Sqlite is to embed the other > functionality alongside it. Both would be linked into the specific > application. For example the people who are eager to have more BLOB > features could do well to have a second file which just stores BLOBs in > their chosen style and links to Sqlite via a key.
On a semi-related note, Sean Chittenden (of FreeBSD fame) created an API from PostgreSQL into memcached (http://pgfoundry.org/projects/pgmemcache/), mainly to allow the database to invalidate objects from memcached that had been updated. I think it would be very interesting to see something similar that would allow using SQLite from within PostgreSQL, since there's a few applications that are difficult to get good performance out of with PostgreSQL. Website session tables that are constantly updated are one example. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
