Your first example creates a table inside a transaction, and actually tries to do a rollback on failure. Many databases don't support transactional support for table creation.

Your second example however doesn't have an explicite rollback. If say, the third insert fails, the eval block leaves, but two rows have been inserted, still waiting for a commit or a rollback. If the program exits afterwards, there will be immplicite rollback, but it's more appropriate to do an explicite rollback on failure.

Also, it quickly pays off of to group the insert into a single statement, especially if the database server is on a different machine. Each ->execute() adds twice the network latency between the machine your code runs on and the database server - on top of whatever needs to be done on the database server.

I also prefer to write the boilerplate as:

local $dbh->{RaiseError} = 1;
local $dbh->{PrintError} = 0;
eval {
    $dbh->begin_work;
    ... queries go here ...
    $dbh->commit;
    1;
} or do {
    my $err = $@ || "Unknown error";
    eval {
        $dbh->rollback;
        1;
    } or do {
        $err .= "[ROLLBACK FAILED: " . ($@ || "Unknown reasons") . "]"
+;
    }
    die $err;
}
[download]

In particular, I rely on the return value of eval to determine whether it succeeded or failed, not $@.