In your connection to DBI, you are testing "$!". Be aware that this won't work as you expect. See the relevant info from DBI docs.
If the connect fails (see below), it returns "undef" and sets both "$DBI::err" and "$DBI::errstr". (It does not set "$!", etc.) You should generally test the return status of "connect" and "print $DBI::errstr" if it has failed.
The delete method is rather inefficient. When called, Class::DBI will issue one DELETE statement for each row in your table. Instead of producing
DELETE FROM page WHERE user_id = 1
DELETE FROM user WHERE user_id = 1
DELETE FROM page WHERE page_id = '1'
DELETE FROM page WHERE page_id = '2'
DELETE FROM page WHERE page_id = '3'
DELETE FROM page WHERE page_id = '4'
DELETE FROM page WHERE page_id = '5'
DELETE FROM user WHERE user_id = '1'
which can be quite long for large data sets.
The sad thing is that, even if I use a database that enforces referential integrity, Class::DBI will still override the database features and issue the same DELETE statements. In your example, if you replace the table definition to use the InnoDB table type, adding
FOREIGN KEY (user_id) references user (user_id) ON DELETE CASCADE,
KEY user_id (user_id)
# and replace "MyISAM" with "InnoDB" for both tables
and the database engine will take care of cascade deletiing the appropriate records in "page".
You said nothing about how DBI::Class handles queries with one or more JOIN, which are quite common in a production environment. This article would be much better if you explained how it works. Without it, it seems no more than an interesting toy.
Snippets of code should be wrapped in
<code> tags not<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).