Yes it works. Yes it is okay. But is it really the abstraction that you want? Masem's solution is much more clean in terms of future expansion. You have to think about why you want to use OO and how you anticipate this will change in the future. In this case you pretty clearly want to be able to add new DB types to the tool. So you should minimize the number of places that need to know about the mapping between DB types and object types. You certainly don't want to have each object know about all of the types.

Whether you can do the detection dynamically and try to load the appropriate code at run time (do an eval based on some identifying attribute like DBI does when loading DBDs) or whether you have a hard coded mapping in some file that needs to be changed each time there is a new DB type is up to you (and the requirements of the problem). Also remember who your target is. If this is for internal use and only you and whomever comes after you need to use it you may want to use a static mapping since it is unlikely that the DB classes will need to be released independent of the main code. If you are going to write a generic tool to release to CPAN that may not be valid.

-ben