
"When the only tool you have is a hammer..."
Ben writes:
Tom Kyte has a solution in PL/SQL that he has presented in a couple of places. I didn't really like it.
I'll check it out, anyway. (IIRC, this is the same guy you mentioned earlier in this thread [or a previous one]; so if he's good enough for you to mention twice [of which one occurrence without the disclaimer, IIRC], he's at least worth checking out for me.)
I generally handle it in a client-side language.
Yeah, I'd kind of like that, too but... [see below]
I've found that to be fairly easy to do in Perl,
Not the language I would choose, I suspect; I'd probably cobble together something in C, or whatever is available on the client's big Unix box. (Yeah, I know... But, hey, we bill per hour!)
and it lets the database focus on what it does best while moving the extra CPU load elsewhere.
Here's the hammer: Not, as you may have thought, that SQL (and Delphi! :-) is all I know, but that our system is implemented on that one single server(*); I don't think we have access to any other.
So, while I could "mov[e] the extra CPU load elsewhere", in terms of taking it out of the database... The only place I could take it, would be "elsewhere" on the same CPU. :-(
(And I don't think that by talking of "client-side language" you're implying I should suck the whole table down onto my desktop PC here, right? :-) Apart from the feeble CPU, this old Win-box doesn't have all that much memory, either... Not to mention the network-bandwidth nightmare it would be!)
(*): Notwithstanding for the moment that "the server" is actually two separate boxes, for development and production, respectively.