<?php
// This is a hack to get around F2S's limitation of only allowing PHP-
+MySQL
$connect = mysql_connect("db.account.f2s.com:3306", "account", "passwo
+rd")
    or die(mysql_error());
$result = mysql_db_query("account", $query, $connect);
while($row = mysql_fetch_array($result))
{
    echo "{\n";
    while(list ($key, $value) = each($row))
    {
        echo "\t$key => q[$value],\n";
    }
    echo "},\n";
}
?>
[download]

sub sql_query
{
    my ($query) = @_;
    my ($data_structure, @data);
    # Ugly kluge to get SQL to work via Perl instead of PHP
    $query = url_encode($query); # TODO: use standard function
    $data_structure = get("http://www.account.f2s.com/sql.php?query=$q
+uery");
    @data = eval "($data_structure)";
    return @data;
}
[download]

--
tune

So, you get a huge performance boost because of connection caching? Is it caching, or multiplexing?

The one problem I've run into before with connection caching is that it tends to keep the connections open. Why is this bad, you ask? Well, every open connection to the database requires resources (mainly memory space). So if your website gets a hard hit, the first few accesses are going to be fast, but you will reach your performance ceiling very quickly.

Also, why would you want to use a programming language that requires a different api for different databases? With perl, it doesn't matter what back end you use, you always get all of DBI's functionality and utility methods.

I would tend to think that php tends to dictate the database backend you use. Just imagine: "We wanted to use <your database software here>, but the interface in php sucks compared to mysql, so we have to use less robust backend software."