in reply to OO design.

In addition to Class::DBI, DBIx::Class, I would look at Rose::DB::Objects. I like the author's answer to your question--he recommends a Person class to hold a person. (One of the first things you'll notice when looking at the CPAN entry is that the documentation is quite extensive, detailed, and thoughtful and even includes a tutorial). The Person class, which inherits from Rose::DB::Object, contains methods to save itself, load itself (based on primary key) and has a "meta" object associated with it for introspection of things like column names and types from the database. However, a Person represents a person, not people. The author then recommends a second class, the Person::Manager class as he calls it, that inherits from Rose::DB::Object::Manager and has methods for complex searches, arbitrary joins, counting, deletes, etc. for dealing with Person(s). The concept was a bit foreign after coming from Class::DBI, which doesn't make as clear a distinction, but it now makes clear sense to me and is a clear answer to your question. I'm not sure where DBIx::Class stands right now on this issue, but before brewing another ORM, I agree that looking closely at what is available (if for no other reason than to learn the different approaches to the problem) is probably going to be fruitful.

Sean