Personally I keep my SQL in a config-like file that lets me load the statements into a hash and keeps the SQL *completely* separate from the perl. My config files look something like this:

[drop]
    DROP TABLE cbwb;
    DROP TABLE cbwb_topic;

[insert]
    INSERT INTO cbwb (id,puser,ptopic) VALUES (?,?,?);
[download]

Note that a hash elements are separated by double-newline, the hash keys are on the first line of the element in square brackets, and the values can contain multiple SQL statements separated by a semicolon+newline combination. For hash values that contain multiple statements, I run them like this: $dbh->do($_) for split /;\n/, $sql{drop};

Another thought is to use dbish (DBI::Shell) which allows you to call SQL statements from named files. That also lets you keep a straight SQL file that has *no* perl in it.

updateOh, I forgot: these days I don't use the square brackets, I put the hash keys in as SQL comments so that the config file is actually all SQL.