Um, a DBA namespace sounds reasonable as a home for cross-database DBA support modules. I'd recommend a structure like this:
DBA::<activity> -- front-end module DBA::<activity>::* -- support modules DBA::<activity>::Plugin::<databasename> -- back-end modules
Sounds good.
But...
And there's always a "but" isn't there?
I'd caution that the "market" for DBA-type APIs that'll work across multiple DBs is small.
There are so many people using Perl and/or DBI to do these things now that I suspect a lot of people would appreciate a standardized solution that they don't have to maintain themselves.
Partly because not many people have significant investment in more than one database of a similar type, but mostly because the lack of standardization of DBA concepts across databases.
Maybe so, but as a developer I have to support dbm, MySQL, PostgreSQL, Oracle, and Informix. (I've got customers on MS-SQL too, but I make sure I'm not dealing with it.) Anyway, having a generic backup solution, query performance analysis, load/unload framework would be phenomenal. Particularly across SQL databases their is a tremendous potential for standardization. The database vendors have worked for years to "differentiate" themselves, but it won't take as many years to brush over the differences as it took them to put them in. Take something that's very database-specific: fragmentation. We can measure fragmentation in N different ways for N different databases and the values may or may not be comparable, but the "defragment" method could be generic (dump and restore) or not.
You'll either end up with a lowest-common-denominator approach that has too little functionality, or have so many database-specific flags an options and whatnot that there's little benefit in having a "common API".
I don't see that. Take backups as our current example: there's a concept that can be implemented in a "lowest-common-denominator" way that's still useful and handy. Giving folks platform-specific options may mean that some local versions end up being somewhat complex, but that would still be a shorter putt than gen'ing up a custom solution every time.
Alzabo does a lot of cross-database translation now and they are able to do it without getting weighed down by rarely used switches.
Having said that, I'd be happy to see this happen if it did :)
Ya ya!
-- </chris>
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
