Mine is a strategy question relating to object-oriented Perl and relational databases.

I'm interested in how people write classes that represent objects in a database, and to what extent operations on an object are mapped onto the database object. The following paragraph from Building a Large-Scale E-commerce site with Apache and mod_perl : Code Structure got me thinking about this again:

Classes in the Model layer represented business concepts and data, like products or users. These had an API but no end-user interface. They knew nothing about HTTP or HTML and could be used in non-web applications, like cron jobs. They talked to the database and other data sources, and managed their own persistence.

I'm curious as to how people actually implement these systems in the real world. As I see it, there are at least two possibilities:

• When an object is created, it requires a unique identifier which ties it to some conceptual object in the database. Each operation on the object triggers a call to the database (eg. calling $person->setName( 'Bob' ) would trigger an UPDATE in the database.) None of the data about the object is actually stored in the object, but in the database. This would mean that the objects were always in sync with the database (since they are only really a thin layer over the database), but would mean a large number of database calls.
• The object has methods like load() and save() that allow it to load the information about the object from the database, then save it back to the database with an UPDATE at a later time. All of the object data is stored in the object, and function calls do not trigger database calls. This would keep the database calls to a minimum, but would mean that objects could be out of sync with the database.

Of course, there may be more ways to do it that I'm just not seeing. How do you do it?

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche