bittondb has asked for the
wisdom of the Perl Monks concerning the following question:

I'm working with an array ref of array refs. This array is the return values from fetchall_arrayref

Code in use:
my $table = $sth->fetchall_arrayref;

Now, I use this array the build a select box. Then I need to fetch a single "row" from $table based on an initial value (a row id). I come from the school of thought that I should just go back to the DB and fetch the single value, but if I already have the table (in $table), then why make the trip to the DB again? I tried messing with map and an anonymous sub but to no avail. I wanted to avoid using a foreach, which I certainly could use, but not as sexy as map. So, what do I do?

Re-reading your post, it sounds like you're wanting to do a little more than just iteration. If 'rowid' is just a column, and you plan on doing many of these look-ups, you can approach this two different ways.
If by 'rowid' you mean the order the rows appear in the database (thus the order they're SELECTed out, though I'm not sure this can be relied on), iteration or direct-access (e.g. $table->[$rowid]) is probably OK for you. If you're wanting to truly search, something like this might be what you're after:

Yes, 'rowId' (actually domainId) is the first column in the table. Lemme expand on what I'm doing. I pull the $table, and then strip the first two columns into a hash, and the first column into a seperate array for the CGI::Form->query->popup_menu method:

Now I need to be able to say, give me the "row" from $table that has a domainId of, say 1. Then I can use the values from that row to fill textboxes for the selected domainId. The search code is great. I was just wondering if there was a way to do it w/ map to avoid the looping code. :)

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.

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). :)

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.