in reply to Search an array ref of array refs

I personally would follow your first hunch and fetch the row from DBI. Why? Databases are optimized for searching the tables, perl is not. SQL is more clear for searching. Just compare the other solutions with a simple SQL query:  select * from table where id=$rowid;.

Another point, the databases mostly scale very well. If your table exceeds let's say more than 1000 items, perl will seriously slow down.

The performance penalty of the additional DBI call moreover probably is pretty small.

Jeroen
"We are not alone"(FZ)

Replies are listed 'Best First'.
Re: Re: Search an array ref of array refs
by bittondb (Novice) on Nov 05, 2001 at 07:37 UTC
    Granted, the search is much more efficient in the DB, but I already have the whole table because I just used it to create a SELECT box on my web page. So the whole genesis behind this was to avoid another round trip to the DB, which IMHO, is more costly (but I could be wrong). :)
[reply]
      What are you optimizing than? Execution speedup cq load time? Are you sure that it takes significantly more time to do an additional query to the server? I guess the connection is not closed between the statement. Maybe the DB is on the same box as the webserver.

      And even if it takes some additional timeframe (probably very small, test it!) for the query, is it worth the worse maintainability of perl code vs the SQL code?

      I generally would answer 'no', but your situation may be different. As ppl say: only optimize the code that needs optimization. Optimization leads to less quality code, so be sure you need it. Just consider what you are doing.

[reply]

In Section Seekers of Perl Wisdom