Jim C. Nasby wrote:
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.
Food for thought.
