I don't agree about most production systems using stored procedures or timed jobs for all updates. I've never seen a system that did that, although I've often heard DBAs wish that things were done with PL/SQL.

Actually, that is our group policy. Selects are done in Perl and anything which alters the database is done via a large library of on-disk stored procedures. Having them on-disk, keep the "business objects" you discuss below out of our already-cramped main memory.

Regarding timed jobs, I once worked at a vote-polling company and we simply needed to push an entirely static website every hour or so. So, we didn't need event-by-event database updates. Just queue them all in a file and do a SQL_LOAD. Also, any digital music company which receives a feed of new music products would more than likely convert this to a SQL loader file and then use the built-in tools. Broadvision, a C++ app server, for instance has this bv_load program that loads its tables much faster than you could do with Perl.

I think it's better to avoid stored procedures as much as possible, but that's a whole different topic.

I hate PL/SQL. I hate writing it. But, I have to admit that server-side processing is much faster than back and forth between client and server.

In my systems, I write Perl classes for each of the data objects I'\ ll be manipulating. These classes handle their own caching.

Let's call these "business objects". This is a good idea. It sounds like the same thing that the BingoX framework is touting, but reportedly their actual ease-of-use is quite low.

denoting the object type as my key in the cache.

And I assume you use Cache::Cache to store your data.