If the target database supports it, I place as much of the sql as possible in a stored proc layer. The stored proc layer can/should contain procs for retrieving, inserting, modifying and deleting business objects - let the stored proc layer handle all the joining and other table maintenance. You as a front-end developer need not worry about it. Once that stored proc layer is in place, you can then automatically create a thin perl wrapper around the stored procs (query the db, find the procs and params - write code to create code). You may need to manually tweak the module but if the proc layer is competently designed and implemented, you shouldn't need to. In the past, I've coded up the thin layer as a 'uses' module that just basically passes everything off to a contained DBI object. You could always subclass DBI, but I always have a more comfortable level by constraining DBI than opening it up for full use.

-derby