note dbwiz A few comments. <ul> <li> 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. <blockquote> 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. </blockquote> </li> <li>The delete method is rather inefficient. When called, Class::DBI will issue one DELETE statement for each row in your table. Instead of producing <code> DELETE FROM page WHERE user_id = 1 DELETE FROM user WHERE user_id = 1 </code> It does <code> 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' </code> 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 <code> FOREIGN KEY (user_id) references user (user_id) ON DELETE CASCADE, KEY user_id (user_id) # and replace "MyISAM" with "InnoDB" for both tables </code> You can then get the same behavior with <code>%dbh->do("DELETE FROM user WHERE user_id=1")</code> and the database engine will take care of cascade deletiing the appropriate records in "page". </li> <li>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. </li> </ul> 279077 279077