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.