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. I think it's better to avoid stored procedures as much as possible, but that's a whole different topic.

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

For example, if I'm building a store and I manipulate data for products, I would make a Product class with load() and save() methods. I'd pass an ID to load. The load() method can then check the cache and go to the database if the object I want is not cached. If it does go to the database, it puts the retrieved data in the cache for future use. I would use the object ID and some constant string denoting the object type as my key in the cache.

It would be very easy to build this kind of thing using SPOPS, and some other tools like Alzabo already do it. My homegrown approach used SQL statements coded in the classes themselves rather than trying to auto-generate them.