Re (tilly) 1: Would you use SQLite?

Why wouldn't I use it?

My use would be a good place to cache data on a local filesystem. Say you have your database server, and several local machines. Suppose that you have a lot of read-only queries where the backing data does not change often.

Well then, why not cache some of the often hit stuff per webserver and not even bother the database unless you need to? The typing issue is unimportant since all of the data is actually managed elsewhere. Since the entire thing (drivers and all) is in one self-contained module, that makes installation even more convenient than MySQL.

UPDATE
After looking at the documentation for the database, read-only cached data looks like pretty much the only thing I would use it for. The locking is incredibly coarse-grained. However there are cases when it is convenient to have an easily-installed read-only data store.

Comment on Re (tilly) 1: Would you use SQLite?

Replies are listed 'Best First'.
Re: Re (tilly) 1: Would you use SQLite? by drewbie (Chaplain) on Feb 23, 2002 at 03:51 UTC
In the same vein, I'd like to see some benchmarks with SQLite vs Cache::Cache, DBM, etc for readonly caches. Since the write lock is global, reading would seem to be it's biggest benefit. If it's faster than Cache::Cache, then you have a potential user in me. :-) As for what I would use it for, I'd probably use it in a project like the one I'm finishing up right now. It is a simple order app with 5 screens. Currently the data is stored in CSV files & read using Text::CSV. And I'm using hidden form elements to maintain state between screens. In this case, it's not worth it to use a "real" database. And I'm not even sure they have access to one. But DBD::SQLite might be just the ticket for this instance. As long as it's simple to compile/install.	[reply]

Replies are listed 'Best First'.

Re: Re (tilly) 1: Would you use SQLite?
by drewbie (Chaplain) on Feb 23, 2002 at 03:51 UTC

As for what I would use it for, I'd probably use it in a project like the one I'm finishing up right now. It is a simple order app with 5 screens. Currently the data is stored in CSV files & read using Text::CSV. And I'm using hidden form elements to maintain state between screens. In this case, it's not worth it to use a "real" database. And I'm not even sure they have access to one. But DBD::SQLite might be just the ticket for this instance. As long as it's simple to compile/install.

[reply]