Responding to this topic in the way that it is naturally flowing ...

What I like to do is to treat the database as a vehicle for persistence, nothing more or less.   Each program that works with the database is drawing from the database to populate its (application specific) “view of the world,”   When a change to that data has been prepared and confirmed, the application then “does whatever it needs to do” to the database(s) to permanently persist that change.   But there should be no assumption that physical database structures “correspond to reality.”   Businesses are always dreaming up new twists on the same old thing, but database structures are not easy to change and in any case must remain compatible with a lot of old code.

And when it actually comes time to do the retrieval and the saving, I find that it really does work (just as) well to use SQL queries.

I recently built a Moose application which is “ye olde shopping cart,” and in this application I made full use of Moose’s ability to easily specify that an object is “storable,” i.e. into the Session store of a web-server.   The shopping cart and all of its contents were thus simply pure-Perl objects; nothing more or less.   They persisted (only) in the Session store until the time came, if it ever did, to finalize the order.   The appropriate objects possessed the ability to populate themselves out of the database and to replace themselves into it, but only they knew (or cared) how it was done.   The strategy worked extremely well.   The design was extremely clean.