This may be a dumb question, but how is this different from the business object mapping that I referred to?

It may not really be that different. It all depends upon how you go about it.

Our internal OO->relational system uses 2 classes for each object. One is the class which fetches/updates/inserts data into the DB. The other is the object (business object) we use in the application. The only thing these two objects need to share is a common set of attributes (object fields, and table columns (or multiple table columns)). The main heart of the system is a mediator object which handles the interaction of these 2 classes. The result is that while we don't get as much for free as you might from something like Class::DBI, with a little more up front work, you can reap many more benefits. The result is that easy things are a little harder than normal, medium things are not much harder than easy things, and complex things are reasonably proportional to their own complexity. From what I have seen with many OO->Relational mappers, the complexity of the implementation rises at a much faster rate than the complexity of the problem itself, and so they can quickly become more of a burdon then an asset.

Now, of course, our system is not perfect, it has its flaws, in particular its very inefficient with large tables (many columns, not many rows). And it cannot automagically handle joins, you have to hand-code the SQL (although it can handle foreign key/link relationships as lazily loaded objects). It is also still pretty much specific to much of the database work we do, so it doesn't handle BLOBs (although it could be made to quite easily, we have just never had a need), and it has only really be tested on MySQL and PostgreSQL.

Some tools may require more custom code than others, but sometimes that extra up-front work is worth it, if you can get some other things for free. I guess my point is that the tools dont always have to be inefficient, and it doesn't have to be an all or nothing deal.