Notice that I left out subselects as a special case. This in my opinion, is the one type of query mentioned that I think could be handled capably by both Perl and SQL. Of course, it holds true to the "depends" hunch, in that Perl would only be more capable if the single SELECT queries were significantly less complex than the case of using a sub-select statement.
Parsing-wise and other operations with text, Perl will win hands down, but looking at scale, the larger the returned dataset from an SQL query, the more load you throw at Perl. So, then you're looking at hardware issues.
Perl can win, but only if your Perl code is optimized and your SQL isn't. Disclaimer: I haven't run any tests to see if I am right, but the only fair test would be to use identical machines (or the same machine for both the perl and the DBMS) in order to fairly test based on code. But after working with the DBI and numerous databases for a year, I just go with what will provide an adequate response from the application. My reply shows what I tend to do in my own code, and in the past, others familiar with the DBI have reviewed my code favorably.
I'll finish by saying that short of trying every variation, you may not find a decent answer. There are optimization tricks in perl, the DBI, and SQL that will all be handy, and as such, it's not an easy question.
ALL HAIL BRAK!!!
In reply to Re: Replacing SQL with perl
by PsychoSpunk
in thread Replacing SQL with perl
by marvell
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |