Lo que dice Cluster es real y lo comparto, si en la implementación de las funcionalidades vuelve a colocar código explícito para cada base de datos, estamos casi al principio del problema
Lo ideal, tal vez, es aplicar un "Patrón Fachada" (Facade Pattern) pero en vez de separar la implementación del código explícito que hace referencia a la base de datos, separar el producto que hace la implementación de la capa de "persistencia" (la idea del patrón de diseño es que no tenga lógica dentro, solo invocaciones).
O sea, crear una clase BaseDeDatos que tiene todos los métodos que nombras, pero en vez de implementarlos, haces invocaciones a los métodos del producto que ofrecen ese servicio.
La ventaja? colocas una capa intermedia propia (BaseDeDatos) y hoy usas ADOdb, pero mañana decides cambiar por otra, o implementar una propia de bajo nivel (que Dios no lo permita
) y tu código "cliente" de estos servicios no se entera del cambio.
Muchachos, dejemos de reinventar la rueda, si no, no avanzamos más. Existen muchos componentes reutilizables, pensemos en innovar y no en repetirnos... hay demasiados productos, por qué hacer otro más?