Next month, I will be giving a talk at Portland Perl Mongers on this topic. A rough description of my talk is as follows:

=head1 NAME

use strict 'sql';

=head1 SYNOPSIS

my $sql  = 'SELECT * FROM that'    and die "Don't do that!";
my $data = $sth->fetchrow_hashref  and die "Or that!";
my $sql  = 'SELECT this FROM that' and die "Still bad";

use base 'Class::DBI';             # much better

=head1 OVERVIEW

Many people misuse SQL.  While some of the above can be fine for a sho
+rt
script, we should be careful about how SQL is used in a production env
+ironment.
C<use strict 'sql';> will detail why the above constructs can lead to
non-scalable code.

First, we'll show some examples of bad SQL and then move on to better 
+SQL with
bad implementations (hint:  I don't avoid C<&DBI::fetchrow_hashref> fo
+r
performance reasons).  We'll finish with a quick discussion of how obj
+ect
persistence modules can help lead us lead us out of the quagmire.

=head1 NOTE

I'll primarily focus on C<Class::DBI> for the object persistence, but 
+I'll
touch on some of the other OO Persistence modules such as Tangram and 
+Alzabo.
I'll also discuss what I think is a bit of a design issue with C<Class
+::DBI>
(sorry Schwern!) and, by the end of the talk, you'll understand why I 
+feel that
way.

Side note:  despite the design issue I alluded to, C<Class::DBI> rocks
+!  Joe
Bob says "check it out!"

=cut
[download]

In short, the thesis is that with proper abstraction of SQL, coupled with adequate tests (you didn't think I'd skip that, did you?), you can build more robust applications and have less worry about database changes, even dramatic ones. Anecdotes welcome! This post is essentially a request for your ideas, insights, experiences, etc, regarding this topic.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)