|more useful options|
A table is not a class, a row is not an instance, and a column is not an attribute.
We've begun using Class::DBI as a layer over the database, but clearly the CDBI is a "storage object", not an "idealized object" (just made up those labels).
Say we have a Zoo, full of Exhibits and Animals and Vets and so forth. We tend to divvy up our tables into logical groups across multiple databases (ease of backup, replication, etc), vs. having every table in the same database. So we might have tables of
And in CDBI, the objects corresponding to the tables would be Animal::Animal, Animal::Medical, Animal::Feeds, Animal::MammalDetail, etc.
So we might have a class Animal (subclassed into Mammal, Reptile whatever), which represents the OO concept of an animal, with corresponding data and methods
And there's also the "storage object" class Animal::Animal, which is just a nice CDBI wrapper around the table Animal.Animal.
We don't force methods onto the "storage objects" (except database-esque methods), and we allow the "idealized objects" to create, hold, and use "store objects" internally to manage their persistence and interaction with the greater system.
So yes, an class isn't a table and a row isn't an instance, but in CDBI-world they are, which is useful and fine. Just don't then try to cram your application-logic into that tiny space, for it is too small and won't fit. Let CDBI or whatever encapsulate the database (highly recommended), then use that encapsulation within a higher "idealized object" that models something meaningful.
Perhaps this ramble makes sense to someone else besides myself... Great thread, dragonchild. Thanks.