A few comments.

• 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
  [download]

  It does
  

  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'
  [download]

  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
  [download]

  You can then get the same behavior with

  %dbh->do("DELETE FROM user WHERE user_id=1")

  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.