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.
In reply to Re: how do you label and cache your database queries?
by princepawn
in thread how do you label and cache your database queries?
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |