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 :-)