Seguro que muchas veces habeis oído que la persistencia de nuestros objetos del modelo debería ser totalmente independiente del Sistema Gestor de Base de Datos (SGBD). En este post se discuten las implicaciones de lograr la «total independencia» frente a otros enfoques como lograr una «baja dependencia». Es una discusión abierta, así que a ver si os animais y aportais vuestra opinión, ideas y experiencias.
Conozco una amplia corriente de mi antigua Facultad de Informática que defiende a muerte la independencia total del SGBD en una aplicación con acceso a datos.
Llamémosla corriente independiente. El enfoque de dicha corriente es que la lógica de negocio se fundamente sobre todo en el proceso y menos en el dato (process driven design). Primero se definen los procesos y lo de menos es su representación persistente. Es el dato el que se adecua al proceso.
En la mayoría de sistemas de producción que conozco hay un enfoque al dato como elemento central de la lógica de negocio. Primero se trabaja con los datos los datos (model driven design) y luego se construyen los procesos sobre ellos. De esta situación se aprovechan los principales fabricantes de SGBDs que incluyen características propias y únicas en sus productos que obligan al cliente depender de él y complica la migración a otros productos de la competencia.
Ambos enfoques tienen pros y contras.
Ser totalmente independiente del SGBD no es una característica a infravalorar, pero suele implicar un esfuerzo mayor de desarrolo o la necesidad de definir un nuevo nivel de indirección. La consulta de datos del modelo persistente, fuera de los procesos de la aplicación, puede ser realmente complicada y oscura. Tareas aparentemente sencillas, como generar claves subrogadas, puede ser tediosa y complicada.
El segundo enfoque suele ser más productivo al integrarse fácilmente con el entorno de desarrollo y se disponen de ayudas y características no disponibles en el enfoque independiente. Por contra, se depende totalmente del producto de un fabricante y si en el futuro surge un SGBD mejor, la migración no suele ser viable por su complejidad.
Mi opinión es bastante práctica y gallega: «Ni una cosa ni la otra».
El esfuerzo de desarrollo de una aplicación para poder hacer migraciones de SGBD totalmente automáticas no suele compensar. Es mejor buscar un bajo acoplamiento con el SGBD encaminado a minimizar las operaciones manuales de migración. Reducireis los tiempos de desarrollo al no buscar a toda costa la independencia total y el tiempo de migración a otro gestor gracias al bajo acoplamiento.
Aun así, valorad siempre si el hacer el desarrollo independiente de SGBD va a ser más costoso en tiempo y recursos que las operaciones de migración en el caso de tener que hacer una a los principales SGBD del mercado.
Para aclararnos: si por conseguir independencia total retrasais unos meses más el tiempo de proyecto, lo único que lograis es aumentar costes de cara al cliente que poco va a entender que dentro de 5 años, cuando otro gestor sea más adecuado, pueda cambiar a él. Por desgracia, lo más probable, es que quiera cambiar gran parte de la aplicación porque ya no se adapta a su modelo de negocio e incluso habrán cambiado las tecnologías de desarrollo.
Además, es muy dificil, por no decir imposible, que aun realizando una aplicación independiente de SGDB, no haya ningún aspecto que os obligue a realizar tareas de migración manuales.
Preguntémonos ¿Cada cuánto cambia de SGBD una organización?
La verdad es que muy poco. De hecho es más probable que cambien antes de sistema operativo que de SGBD. No deja de ser un argumento un poco capcioso y circular porque la corriente independiente defiende que en la variedad está el gusto y si tienes la facilidad de cambiar probablemente lo acabes haciendo. Sin embargo me cuesta pensar que aun teniendo la posibilidad, una organización esté cambiando de SGBD cada año.
Personalmente me parece una pérdida de tiempo, de esfuerzo, de recursos… el buscar la independencia de SGBD a toda costa y defendiendo radicalmente que es un requisito imprescindible, haciendo capas y capas de indirección y archivos de configuración. Sobre todo para proyectos pequeños o medios.
Desde mi punto de vista y hoy por hoy, el camino está en hacer nuestros modelos de datos menos dependientes del gestor, menos acoplados, valorando siempre el tiempo de migración a los principales SGBD. No suele llevar mas de un par de días de trabajo y te ahorrará disgustos en el futuro.
A continuación os doy algunos consejos para lograr bajo acoplamiento:
Consejos para conseguir modelos de datos menos acoplados
Utiliza una herramienta como ErWin o Embarcadero para generar el modelo de datos. Automáticamente pueden generarte las sentencias SQL para crear y modificar un modelo de datos entre distintos gestores. Concretamente con ErWin hemos migrado esquemas entre Informix (7.61), SQL Server 2000 y Oracle (8-10) sin prácticamente ningún problema. Ambos son de pago (y no son baratos), desconozco si existe alguna solución opensource o gratuíta.
Si no dispones de ese tipo de herramientas, mantén siempre un archivo SQL con el esquema de tú modelo, con comentarios etc… de forma que sea muy fácil recrearlo.
No confíes en que un EXPORT del SGBD te lo va a generar completo directamente o cómo tu quieres.
Utiliza tipos de datos que sepas que son compatibles entre los principales SGBD.
No uses procedimientos almacenados. No hay dos lenguajes de SPs iguales. Si tienes que usarlos que sean mínimos e intenta utilizar palabras clave que sepas que existen en otros gestores o tienen mecanismos análogos. Desde luego, implementar la lógica de negocio en ellos es un diseño que pertenece al pasado, además de atarte irremediablemente al SGBD al complicar la migración haciéndola prácticamente inviable. Análogamente no deberías usar ensablados en el SGBD (característica de SQL Server 2005).
Cuidado con la generación de claves subrogadas. En algunos gestores se utilizan secuencias (Oracle) y en otros columnas de identidad con autoincremento (SqlServer, Informix).
En general, no utilices ninguna característica propia del SGBD. Suelen ser atractivas a la hora de programar pues resuelven algún problema tedioso, pero te ligan al SGBD.
No definas una política complicada de permisos. No suele ser compatible entre gestores y son de díficil migración. En la mayoría de escenarios basta con un usuario administrador, otro con permiso de escritura y lectura de tuplas (writer) y un último usuario con permisos de solo lectura (reader). Además, usar pocos usuarios beneficia a entornos con concurrencia optimista (p.e. desarrollos web) porque el pool de conexiones puede reutilizarlas al coincidir las cadenas de conexión.
Utilizar un mapeador de objetos relacional. Como por ejemplo Hibernate, (NHibernate para .Net). Te pueden aislar totalmente del SGBD. Te mapean la persistencia de tus objetos del modelo, que deberían ser clases POCO, POJO (Plain older C# Objects, Plain Order Java Objects), incluso con soporte para herencia contra los principales SGBD del mercado. Es decir, te evita hacer la parte más tediosa de los DAOs. Dispone de lenguaje propio de consultas (HQL) parecido a SQL. Soporta generación idependiente de claves subrogadas y gestión de transacciones. En el framework de java es capaz de trasladar esquemas (modelos) entre gestores, haciendo parte del trabajo de herramientas mencionadas en el primer punto. Direis: «Vaya, si es tan fantástico… ¿porqué no lo usa todo el mundo?». Existen varias razones: Una es que no es trivial su uso. Es una tecnología relativamente reciente y se necesita cierto background en SGBD para ponerlo a funcionar y solucionar problemas eficientemente. Si tienes poca experiencia, puedes hacer mapeados aparentemente correctos que son totalmente ineficientes. Añade un nivel de indirección más para el acceso a datos. Para proyectos pequeños o medianos puede ser inviable. Dejo para un post futuro un análisis más profundo de NHibernate con ejemplos.
Una discusión sin final
Se pueden estar horas y días discutiendo los puntos anteriores. Sin embargo solo vosotros, como responsables de proyectos, sois los únicos que podeis valorar cada situación y una solución perfecta para un escenario puede ser catastrófica en otro.
Si vuestro trabajo es ofrecer soluciones a un cliente (suele ser el tipo de trabajo más común para un informático), un último consejo: Buscad siempre
Hoy en día, y sobre todo si desarrollais con VisualStudio y .NET, SQLServer 2005 es una de las mejores opciones como SGBD. Sobre todo si pensais que oracle es demasiado grande, caro y dificil de administar (instalación de parches, etc.). Actualmente SQLServer se integra mejor que Oracle en Windows y VisualStudio, escala muy bien y no se emplea exlusivamente para proyectos pequeños o medios. Podeis empezar con SqlServer Express Edition que es gratuito y ofrece las principales características de SQLServer 2005. Si vuestro proyecto crece os podeis actualizar a SQLServer 2005.
Las herramientas para administrar el gestor y realizar consultas, son más cómodas que las que he utilizado en Oracle. Aunque las de este último no las he valorado a fondo ni he buscado alternativas aparte del DBVisualizer.
Por último os dejo un diálogo del film «La vida de Brian» que ilustra sarcásticamente esta discusión.
Unos activistas del Frente del Pueblo de Judea están reunidos en un circo romano …
Stan: Todo hombre tiene derecho a tener bebés,si los quiere.
Reg: Pero tú no puedes tener bebés.
Stan: No me oprimas.
Reg: No te estoy oprimiendo, Stan; tú no tienes una matriz. ¿Dónde se va a gestar el feto? ¿Vas a mantenerlo en una caja?
(Stan comienza a llorar.)
Judith: ¡Ya! Tengo una idea. Supongamos que ustedes están de acuerdo en que él efectivamente no puede tener bebés, sin tener una matriz, lo que no es culpa de nadie, ni siquiera de los romanos, pero el puede tener el *derecho* a tener bebés.
Francis: Buena idea, Judith. Combatiremos a los opresores por tu derecho a tener bebés, hermano. Perdón, hermana.
Reg: ¿Cuál es el motivo?
Francis: ¿Qué?
Reg: ¿Cuál es el motivo de combatir por su derecho a tener bebés, cuando él no puede tener bebés?
Francis: Es un símbolo de nuestra lucha contra la opresión.
Reg: Es un símbolo de su lucha contra la realidad.
Activistas en “La vida de Brian”, film de los Monty Python. Gran Bretaña, 1979, diálogo extraído de http://www.zonamoebius.com/004/brian.htm
Muy bueno, yo también debo tener algo de gallego ya que mantengo lo de «Ni una cosa ni la otra».
Por supuesto lo de «Buscad siempre la productividad a costes razonables» debe ser una máxima.