Alternativas al SQL

Hace tiempo que el SQL es una gran opción para hacer consulta de datos ¿pero no habrá otra cosa?. No es por estar desconforme con el SQL, pero cuando nos encontramos con programación orientada a objetos y queremos guardar por algún motivo un objeto tenemos un pequeño problema.

En si me encontré con este problema en el trabajo cuando por razones técnicas o de mercado analice el reemplazo para el Visual Basic 6. Este se debía hacer por dos motivos fundamentales:

1. Microsoft saco el VB.NET, es decir toda la plataforma NET y queramos o no el mercado y la tecnología se moverán en este sentido.
2. En la empresa en la cual trabajo aproximadamente la mitad de los equipos tienen instalado una versión de Linux (Suse).

Al tener equipos con Linux la plataforma NET (si bien hay intentos en concreto para llevarlos al Linux como ser el proyecto MONO) entrar de lleno con NET resulta un poco complicado. Así que analizamos otra tecnología que hace tiempo ofrece portabilidad sin tener en cuenta el Sistema Operativo Java.

Nuestros servidores corren con Unix (SCO), lo que hacíamos en VB6 eran solo son pequeñas aplicaciones, que en general su objetivo es hacer algún tipo de planilla o informe gráfico sobre los datos que manejamos.

El primer intento que realice con Java fue conectarme con una base de Access pero si bien esto se puede lograr sin mayores problemas, el tema es como portar esta base a Linux, así que no tenía mucho sentido usar una tecnología portable como Java con una base de datos que no fuera también portable a otros Sistemas Operativos. Para reemplazar el Access necesitaba algo que cumpliera con las siguientes características.

1. Que fuera compatible con JDBC pero que estuvirea este driver escrito en puro Java o bien que no dependiera del sistema operativo.
2. Que pudiera usarse en modo servidor y también abrirse para mono usuario sin mayores problemas. El MySql es muy bueno pero para una pequeña aplicación mono usuario y que no se utiliza todo el tiempo es un poco complicado.
3. Si tiene un bajo costo o es Open Source mejor.

Como se ve en estos tres requerimientos la situación no parecía fácil. Pero buscando me encontré con el HSQLDB. Que casi milagrosamente cumple los tres requerimientos. Es más realice unos prototipos usando este paquete que dieron unos resultados muy alentadores.

Pero si tengo que guardar objetos en una base de datos la cosa se complica un poco un detalle resumido de lo que hay que hacer es esto (seguro que lo vieron antes en otro lado):

• Crear una base datos con toda su estructura y campos de acuerdo con los objetos que deseamos guardar
• En los objetos escribir todo el código para poder guardar los datos en la base.
• También escribir todo el código para poder recuperar los datos cuando se trate de recuperar el objeto previamente guardado.

Si bien así escrito parece poca cosa es cuando nos enfrentamos al trabajo es un montón de código. No que es que esto este mal en si, pero lleva bastante tiempo hacerlo. Como es lógico no fui el primero que se encontró con el problema (siempre alguien te gana de mano) en este caso no solo me ganaron de mano si no que también se pusieron a trabajar. Así que me baje una versión del Hibernate cuando me entere con mucha alegría que este soportaba al HSQLDB.

Cuando experimente con el Hibernate y me encontré con que:

• Hay que seguir armando la base de datos.
• Tenemos que mapear la base de datos para que el Hibernate realice su trabajo.
  

Descubrí que para desarrollar una aplicación esto lleva tiempo, mucho menos que la opción anterior pero para una pequeña aplicación o cuando no tenemos mucho tiempo para programar (en mi caso programo pequeñas cosas para mi por gusto o bien para entender mejor el idioma que en el cual voy a desarrollar y lamentablemente no dispongo mucho tiempo para hacerlo), así que necesitaba algo de dispara y olvídate. Justamente eso es lo que encontré con el DB4O. Cual es su ventaja, un espectacular ahorro de tiempo

• No hay que diseñar una estructura en la base de datos. Solo hay que guardar los objetos en la base (perdón contenedor de Objetos), lo que no supone mucha perdida de tiempo ya que a las clases hay que crearlas de todos modos.
• Si después hay un cambio de en las clases, bueno no hay estructura que arreglar simplemente se guarda el objeto como siempre y el DB4O se encarga de todo el trabajo molesto adicional generado por los cambios en las clases.
• El único inconveniente con que me encontré es que nos tenemos que olvidar de las consultas SQL clásicas pero después de un tiempo de usar este tipo de almacenamiento no las extrañas mucho (dependiendo del tipo de sistema que se quiera desarrollar).
• Sobre la técnica del mapeo objeto - base de datos. Tiene la ventaja fundamental que no hay nada que mapear y la aplicación resultante tiene menos módulos, ya que si bien el DB4O 5 o 6 archivos jar que agregar al proyecto. Parece más simple o son menos que cuando tenemos que agregar los correspondientes a la base de datos y el patrón de mapeo.
• Y una ventaja adicional más esta también esta disponible para la plataforma NET.

Por experiencia lo que pude ver es que siempre hablando de pequeños proyectos es mas simple usar este tipo de tecnología (guardar directamente los objetos) que otra mas tradicional (SQL + Mapeo). Por lo que vi tampoco creo que en un proyecto mas complicado o para testear desarrollos más grandes este de todo mal el tipo de tecnología que usa DB4O. La verdad creo que por el momento esta forma de trabajar no va a desplazar al SQL pero es una alternativa aceptable para no perder de vista.