Dear Aristotle

It surprises me that this excellent study you shared with us (++) didn't take you to Class::DBI & friends. IMHO this approach is nicer because you simply do not see any more SQL mixed with your Perl. Granted, this may be a significant paradigm shift and perhaps there are things that get harder to do with this model.

The fact that no monks have mentioned this yet makes me think that there is something in your node that I missed :) But anyway, I would like to share my experience with the fellow monks.

With Class::DBI you write a (very simple) class hierarchy that describes your tables, columns, relationships. This can be even simpler if you accept to specify within those classes, which database you will be using. In this case you wouldn't even have to name your columns at all.

That class hierarchy really helps a lot with code reuse and encapsulation.

Then, all of a sudden, everything becomes nice, packaged objects with accessors that are mostly DWIM-compliant. There are additional classes that support complex query generation (even supplying your own SQL).

There are some wrinkles to iron yet, but in my experience, this family of modules has changed my way of working. I really like this style better and I have seen how cleaner your programs can be. I rewrote some production code (DNS::BL) so that it uses Class::DBI rather than hand rolled code, and I'm very happy with the results.

BTW, it also plays nice with Apache::DBI...