in reply to Re: Re: selecting again from a mysql database
in thread selecting again from a mysql database

if you are using bind_columns (which is, after all, the fastest way to fetch), then this is fine

That's a reasonable example. It's still slower at the database level, though.

You want to display a table to examine it's structure visually, without knowing its structure in advance.

Looking over the structure of the data falls under interactive use (though you're probably better off using something like MySQL's describe [table] command), which is the reason why SELECT * works at all.

If you're writing code for a real application, you ought to know what the columns are. If you don't, look them up. If you can't look them up, you've got other problems (either poor documentation or bad internal politics). The only exception I can think of to this is when you don't know what table you'll be using in advance (though I'm not sure about even that case).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Re: Re: selecting again from a mysql database
by mpeppler (Vicar) on Nov 25, 2003 at 21:15 UTC
    That's a reasonable example. It's still slower at the database level, though.
    This may depend on the actual database you are using. I suspect that unless the table is really wide the difference in speed at the database level between "select col, ..." and "select *" is really minimal.

    After all, the SQL parser still has to resolve the columns that are passed in to the query and make sure that they exist, what type they are, etc.

    That said I agree that "select *" should be avoided in anything but throwaway code as it is generally an indication that the programer doesn't have a clear idea of what s/he wants.

    Michael