I would suggest this general approach:   create a base-class (use base blah;) which will be the ancestor of all of the data-access objects in your application (even if, as is quite likely, they are in turn based on something else from CPAN).   All of the functionality which is truly common between all of these objects is moved up to the base class.   (Constructors and so-forth exist within the children and they first call their SUPER::s.)   Issues that need not be visible to any client of the class, such as how to get database-handles when needed, would be dealt with there.)

But now, let’s talk about philosophy.   (The following is, of course, IMHO.)

A data-access object like this one should represent what this application needs to do with a particular item-of-data that is of interest to it.   This item-of-data might correspond to a single database table; or, it might not.   The public methods that are exposed should represent the means by which the rest of the application does things and how it knows things, such that unnecessary implementation details are concealed inside.

Provided that the interface is “purposeful,” consistent, and clear, many other things are quibbles.   “There’s More Than One Way To Do It.™”   I suggest that you plan (before actually writing any code ...) what you think the set of objects and their associated public methods ought to be, so as to do what your application does, and to provide your application with what it needs to know along the way.   Put some serious advance thought into it, focused first on “what, not how.”