Humanética

HSQLDB

Sí, estoy probando este motor de BD.

Fue Al quién me indicó de su existencia, cuando yo andaba perdido por unos oscuros caminos pensando que lamentablemente no había una alternativa para Access para algunas aplicaciones de escritorio (y hay mas de una por supuesto ;-), pero como no puedo probar todas me decidí por HSQL). Access no me convencía (a pesar de que dentro de su categoría, como BD de escritorio, la considero una de las mejores) por las siguientes razones:

1. Solo funciona en Windows. De modo que mis aplicaciones iban a quedar “amarradas” a ese SO.
2. Parece no entenderse tan bien con Java. No es que existan problemas graves entre ellos, pero el hecho de usar un puente ODBC-JDBC no me agrada (consideren que además tiene que hacerse la conversión de ODBC al motor propio de Access).
3. No tengo licencias para usarlo. Y aunque el usuario final no necesita tenerlo instalado para que funcione yo si lo necesito para desarrollar.
4. Para utilizar Access a través de la red hay que compartir la carpeta correspondiente con permiso de escritura. Es decir, no se puede (que yo sepa) hacer que el motor de Access sirva los datos a través de un puerto utilizando TCP/IP.
5. Muchas veces tiene problemas en el trabajo con multiples usuarios simultáneos (porque todos modifican un archivo temporal que guarda no sé que información).
6. Cuando no se compacta, crece y se hace tan lenta como una tortuga. Hace unas semanas he visto un programa (Visual Basic con Access) funcionando en una PIV con 128 MB de memoria y se demoraba “un siglo” para hacer unas consultas relativamente sencillas. La BD pesaba más o menos 100MB. Como ya sabía de este problema, lo primero que hice fue compactar la BD y se redujo a 2MB. La velocidad ... quedó como siempre debería haber estado. Bueno, eso se puede prevenir haciendo que cada cierto tiempo se compacte la BD. Y creo que HSQL tiene un comportamiento parecido en este aspecto.

Vayamos por HSQL. Esta escrito totalmente en Java, por lo que es portable. Tiene un driver JDBC que incluso se puede usar de forma embebida dentro de la aplicación. Es software libre (Licencia BSD). Se puede operar de varios modos, que se pueden agrupar en enProceso (In-process) y Cliente-Servidor(Client/Server). En el primer caso solamente puede tener una conexión abierta (dentro de la misma máquina virtual), y en el segundo (que a su vez tiene varias alternativas) sirve los datos a través de un puerto (9001 de forma predeterminada) y admite n conexiones. También necesita compactarse para optimizar su rendimiento lo que se puede hacer al cerrar la BD, utilizando “Shutdown Compact” (en vez del simple “Shutdown”).

En en mismo archivo jar vienen algunas herramientas administrativas, una de las más utiles es el DatabaseManager hecha con AWT (la versión Swing no me funcionó). Mediante la cual se pueden enviar sentencias SQL al motor para modificar la BD o recuperar registros. Pero lo mejor, se puede “enchufar” cualquier otra herramienta administrativa que soporte utilizar drivers JDBC, como DbVisualizer, AquaData Studio, etc. Este dato se lo debo a Martín.

Hasta el momento, estoy satisfecho de como se ha portado este motor. Es rápido. Acepta una buena cantidad de sentencias SQL estándar, y esta perfecta para varias de mis necesidades. Entre algunas cosas interesantes, se puede escribir stored procedures utilizando como lenguaje java.

Todo lo dicho no quita que no tenga dificultades que sortear (como todo en la vida). He aquí algunas de las que me encontré hasta ahora:

1. Existe la posibilidad de crear varios tipos de tablas: TEMP, MEMORY, CACHED y TEXT. El tipo predeterminado (cuando se usa un simple Create Table sin especificar tipo) es el MEMORY. Algo de lo que no me había percatado al principio. En este tipo de tablas, cada vez que se inicia la base de datos, toda la información es cargada en memoria. Cuando se realiza un cambio ya sea en la estructura o en el contenido se almacena una sentencia que la representa en el archivo bdatos.script, para poder utilizarlo en la próxima vez que se vuelva a iniciar la BD (pero no para consultar los mismos durante el funcionamiento). Por supuesto que si se va a usar tablas con un número alto de registros se puede sobrepasar el límite de memoria y traerse abajo la BD. Su ventaja es que esto le da rapidez. Para mis fines presentes, prefiero las tablas tipo CACHED (o quien sabe las TEXT).
2. Las BD son case sensitivity, de forma predeterminada, para los campos de texto (comparación e indexación). Hay forma de cambiar esto mediante SET IGNORECASE{TRUE | FALSE}. Sin embargo, esto no afecta las tablas creadas y datos almacenados. Cuando se activa esta opción los campos VARCHAR son creados en realidad como VARCHAR_IGNORECASE, el cual es un tipo de dato especial para que las comparaciones se hagan sin tomar en cuenta si es mayúscula o minúscula. Lo bueno es que igualmente se pueden crear campos con este tipo de datos sin cambiar la opción en toda la BD, pudiendo coexistir en una tabla datos VARCHAR y VARCHAR_IGNORECASE. Una vez con este conocimiento esto representa una ventaja, por supuesto.
3. Para crear campos autonuméricos se puede utilizar IDENTITY en la definición del campo. Lo cual lo hace automaticamente de tipo INT, autoincremental y clave primaria. Sin embargo, la numeración empieza en 0. Y yo estoy acostumbrado a que se inicie en 1. Hasta ahora no he encontrado forma de modificar este valor por defecto, a no ser que sea insertando un registro y poniéndole un valor al campo (pero esto es lo que quiero evitar).
4. El conjunto de funciones para el manejo de datos es limitado. Por ejemplo estaba buscando funciones para el manejo de fechas. Los típicos DATEDIFF, ADDDATE(o DATE_ADD), o alguna otra forma de sumar o restar tiempo a una fecha. Y no, creo que no funcionan. Me fuí al Foro de SourceForge y leí que se pueden implementar las funciones en Java para luego utilizarlas de manera trasparente desde las sentencias SQL (“pero por supuesto”, pensé, “¿cómo no se me ocurrió antes?”). Así que eso es lo que voy a intentar. Pero todavía no sé como hacerlo. Estoy suponiendo que es como crear cualquier otro procedimiento almacenado en otra BD, pero no estoy seguro. Si alguién ya lo hizo que me cuente y me ahorre algo de tiempo ;-). Sino, de todas maneras espero poder pasarles luego esa información.

Posted at 03:02AM May 03, 2004 by Ricardo in Java  |  Comentarios[9]