I agree with this approach. It is a recognition of the fact that in the real business world, database tables are usually the master of the data. Objects may be thought of as a temporary, programming-language-based, in-memory views of database query results. There may be other applications that derive entirely different "objects" from the same tables, and even report applications driven by straight SQL queries with no attempt at object orientation.

The Class::DBI module commits what C.J. Date calls the First Great Blunder, attempting to equate objects with rows in a relational table. Date advocates using objects only for user-defined types (things like geographical shapes), confined to single column types instead of row types.