One more trick usable with DBD::mysql is mysql_read_default_group ,an option to have a configuration file with credentials for different applications.

First, you need to create a configuration file, with different [label]s.

# $HOME/.my.cnf

# Here are some general options
[client]
socket=/tmp/mysql.sock
port=3306

# the following are specific to each application

[mysqldump]
user=dumpuser
password=not_my_pwd

[backup]
user=bkpuser
password=not_my_real_one

[usage]
user=simpleguy
password=not_this_one

[readonly]
user=poorguy
password=don_t_try_it

[myapp]
user=specialguy
password=something_different
[download]

Then, in your code you can refer to such labels this way:

my $dbh = DBI->connect("DBI:mysql:test"
    . ";mysql_read_default_file=$ENV{HOME}/.my.cnf"
    .';mysql_read_default_group=myapp',
    undef, 
    undef
   ) or die "something went wrong ($DBI::errstr)";
[download]

This code will use the label [myapp] from the file $ENV{HOME}/.my.cnf.

To use a backup application, replace myapp with backup in the above code and your application will use that username and password under [backup].

You can also use this trick to test the same application with different users having different access profiles. (Update. - I mean database users, not O.S. users)

my $profile = shift || 'usage';

my $dbh = DBI->connect("DBI:mysql:test"
    . ";mysql_read_default_file=$ENV{HOME}/.my.cnf"
    .";mysql_read_default_group=$profile",
    undef, 
    undef
   ) or die "something went wrong ($DBI::errstr)";
[download]

BTW, the article you were referring to is mine, also published in my blog.

Update - While mysql_read_default_file adds to security, because you won't leave your password hardcoded in your script and you can store it outside the document tree in web applications, using mysql_read_default_group is only a matter of convenience. Using it does not add to security, but just to tidiness.

 _  _ _  _  
(_|| | |(_|><
 _|