I'm not sure whether I'd use SQlite, as I use databases mainly for two purposes :

• Data storage - of course, with the amounts of my stored data, I could most likely keep the whole stuff in memory and wouldn't need a "real" database for it.
• Process coordination/serialization - most "real" databases have internal protection against multiprocess issues, so I can offload the burden of maintaining a locked list to a database. I can easily set up producer/consumer relationships via a database table without having to worry about locking and stability; I can even upgrade a consumer or a producer on the fly without the other half noticing.

For the data storage part, the SQL syntax helps much here, as it makes searching easier to comprehend unless you want to do fancy (re/grep) searching. SQlite would help with the expandability/portability of the solution, as I could go from a flat file to a "real" database anytime.

I guess that, to use SQlite as a scheduler/coordinating entity, I would have to start a "SQlite SQL server" (you heard it first on http://www.perlmonks.org), which opens sockets, and have some "special" DBD driver for my other processes to connect to the central server to cope with forked childs. This is not necessarily bad, as there is no other administration overhead with this SQL server, but on the other side, such a SQL server could be written independant of the underlying storage structure; it would be possible to have a server over DBD::CSV as well.

These are my raw thoughts, if I come up with more points, I'll add them to this node ...

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]