Conclusiones finales
Después de haber trabajado algo más de un mes con PostgreSQL nos damos cuenta de que es una herramienta mucho más potente y completa de lo que se pudiera pensar en un principio. Hemos empezado de cero, sin apenas haber oido hablar de este gestor (la publicidad la tienen Oracle y MySQL). Rápidamente buscamos en su web instrucciones de cómo instalarlo. Al poco nos dimos cuenta que en los cds de casi cualquier distribución de Linux venía incluido.
Una vez instalado, empezamos a trabajar con él. Entonces nos surgió el problema de que una base de datos no es algo tan portable como el código fuente de un programa o un documento, no podíamos meterlo en un disquete o zipearla y enviarla para ver los progresos se cada uno. Teníamos que encontrar el modo de trabajar concurrentemente sobre una base de datos (que al fin y al cabo es uno de los objetivo de los gestores de bases de datos). En tonces se nos ocurrió utlizar conexiones mediante ssh. Así podíamos trabajar sobre la misma base de datos alojada en el ordenador de uno de nosotros.
Una vez resueltas con éxito estas cuestiones, empezamos a trabajar en el problema que nos habíamos propuesto. Tras realizar el diagrama Entidad-Realación y pasarlo a tablas, comenzamos a codificarlo en SQL. Aquí se nos presentó otro problema. Aún no sabíamos nada de SQL (sólo habíamos creado bbdd con asistentes visuales de MS-SQLSever™). Entonces con paciencia, manuales y tirando de google hicimos un pequeño boceto. Especialmente traumático fue comprender el uso de los CONSTRAINS para las claves ajenas (es increíble la cantidad de nombres que se les da a las claves ajenas: ajenas, extrajeras, foráneas, externas, exteriores...). Una vez comprendimos esto, hicimos un primer boceto en SQL de nuestra bbdd, que ya incluía tipos de datos y claves primarias y ajenas. Esto nos daría pie a poder empezar a desarrollar el programa que accediera ella.
Tras añadir muuuuchos datos (siempre a través de sentencias SQL) empezamos el desarrollo del programa. Elegimos el lenguaje de programación Python, por conocerlo previamente y por lo que necesitábamos en este momento: velocidad de desarrollo y una gran interconectividad con Postgres (No sólo de Python vive Postgres evidentemente; existen módulos de conexión a Postgres para C, Java, Perl, Pascal y un largo etcétera.). El programa avanzaba rápidamente. Decidimos que su única funcionalidad sería la de añadir datos. Que no era una tarea sencilla, debido sobre todo al gran número de relaciones entre las tablas. Por no multiplicar líneas de código, decidimos no realizar demasiadas comprobaciones de error en los datos introducidos. Ya se encargaría de protestar Postgres.
A medida que avazábamos nuestros conocimientos en SQL crecían. Realizábamos consultas complejas y empezamos a mejorar el diseño inicial de la bbdd. Afinamos un poco los tipos de datos obtenidos e introdujimos CHECK en muchos atributos y otros detalles. Luego descubrimos que pgaccess podría habernos ahorrado el trabajo de aprender tanto SQL pero siempre es más importante conocer lo que hay que hacer, que dejar a una aplicación que lo haga (sobre todo si no sabemos exactamente lo que esta aplicación hace). Sin embargo hubiera estado bien haber prestado más atención a pgaccess al principio.
¿Qué hemos aprendido? Pues entre otras muchas cosas hemos aprendido a:
- Instalar y configurar un servidor PostgreSQL en un entorno Linux
- Preparar una máquina Linux para permitir accesos remotos de modo seguro
- Programar una aplicación que se conecta y utiliza una base de datos
- Un montón de SQL
- Utilizar una aplicación gráfica como pgaccess para manipular una bbdd
- Escribir y compilar documentacion en DocBook/SGML
No queremos olvidarnos de comentar un último detalle muy importante. Todas las aplicaciones que hemos utilizado son software libre (puedes redistribuirlo y modificarlo según sus respectivas licencias) y está disponible de manera gratuita. El coste por software del problema que hemos descrito e implementado asciende a 0 euros. Eso sí, la mano de obra ha de estar bien remunerada :-)