in reply to Looking for neater solution with dynamic query

Are you looking for performance benefits from using prepare and binding parameters, or security benefits, or code-cleanliness benefits, or?...

To get the security benefits, I'll often maintain two parallel structures: one with the query with parameters replaced by ?, and another with all of the parameters that should be used in execute. For example:

$query .= ' where upper(env)=upper(?)'; push(@sql_params,$query(env}); ... my $sth = $dbh->prepare($query) or die; $sth->execute(@sql_params);

Getting the performance benefits isn't as easy, but there aren't performance benefits unless you're in a long-running environment (like mod_perl) and frequently repeat the same query. If that's the case, if you can come up with a few parameterized queries, you can prepare all of them, then just pick the right one. For example, it looks like there are only 8 possibilities in your sample code, so you could store these 8 queries in an array, then pick the right one and send it the right parameters.

Also, you can simplify the way you append to the query by using an array and join (untested, but you get the idea):

if (defined($query{component})) push(@querypart, 'where upper(component) = upper(?)'; push(@sql_params,$query{component}); } if (defined($query{env})) { push(@querypart, 'where upper(env) = upper(?)'; push(@sql_params,$query{env}); } $query = 'SELECT * FROM or_mod ' . join(' AND ',@queryparts) . ' order by env, application, component, mod_date, desc'; print $query; my $sth = $dbh->prepare($query); $sth->execute(@sql_params);

Replies are listed 'Best First'.
Re^2: Looking for neater solution with dynamic query
by eric256 (Parson) on Aug 24, 2005 at 22:27 UTC

    Unless I missed something I think there are only 4 possiblities.

    my $queries = ( "SELECT * FROM or_mod;" "SELECT * FROM or_mod WHERE upper(component) = upper(?)"; "SELECT * FROM or_mod WHERE upper(env) = upper(?)"; "SELECT * FROM or_mod WHERE upper(component) = upper(?) AND upper(env) = upper(?)"; ); my $sth; my @bind; if (defined($query{env}) &&(defined $query{component}) { $sth = $dbh->prepare($queries->[3]); $sth->execute($query{component}, $query{env}); } elsif ( defined ($query{env}) ) { $sth = $dbh->prepare($queries->[2]); $sth->execute($query{env}); } elsif ( defined ($query{component}) ) { $sth = $dbh->prepare($queries->[1]); $sth->execute($query{component}); } else { $sth = $dbh->prepare($queries->[0]); $sth->execute; }

    I'm not entirely sure that is much better than dynamicaly generating them, or better at all for that matter. In fact I think the dynamic solution is better because it is dynamic. BTW newer MySQL caches all queries whether you ask or not, I don't know if that holds for bound queries as well. If it does then as long as you are binding, even if it seems lame for this single call, it will give you benefits in the long run.


    ___________
    Eric Hodges

      I had this thought... the problem is that this cannot be used as a generic solution, as one can easily run into queries that have more complex where conditions.

      However there is one benefit, the queries are now real prepared/binding queries. It is a taken and given thing. I decided to pass.