In addition to the comments that jeffa made regarding the performance benefits of using placeholders in DBI statements (the question mark), I'd like to mention something else about them.

Using bind variables can also plug up significant security holes. Imagine what happens if someone using the program manages to set $header to the following:

foo';DROP TABLE press_release;SELECT * FROM press_release WHERE header
+='foo
[download]

For databases that allow multiple SQL statements separated by semi-colons, this is how the SQL gets interpreted:

SELECT id FROM press_release WHERE header = 'foo';
DROP TABLE press_release;
SELECT * FROM press_release WHERE header='foo'
[download]

The last statement is a throwaway, but because the cracker has taken the time to balance the quotes, the database will happily attempt to execute all of the SQL statements. These may or may not succeed (depending upon permissions, foreign key constraints, etc.), but a cracker should never get this close to touching the database. Placeholders, in addition to benefitting performance, also plug this potentially huge security hole.

You can also protect yourself with the following changes:

$header    = $dbh->quote( $header );

# note the *lack* of single quotes around $header
$header_id = $dbh->prepare("SELECT id FROM press_releases WHERE header
+ = $header");
[download]

This works, but there are two problems with it:

1. You lose the performance benefits of using placeholders and bind variables.
2. It's easy to forget to quote the variable.

Stick with placeholders and your scripts will be much more secure.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.