NachXs Blog

Hace poco el grupo de desarrollo de PostgreSQL libero la nueva versión 8.3 beta 1, con muchas novedades interesante, toda la información aqui

XMLtoPgSQL, es una pequeña aplicacion que desarrolle sobre Java que consiste en analizar un archivo *.xml generado por DBDesigner a partir de un modelo de datos y llevarlo a un archivo *.sql definido para PostgreSQL. En un post anterior publique algo sobre este tema el cual consistia en realizar el mismo proceso, el cual lo estaba desarrollando sobre Mono y Glade, pero por el momento lo deje en Stand by, ahora lo retomare utilizando como base este pequeño algoritmo y hacerlo funcional.
Pues si lo desean, genere un archivo *.jar el cual lo podemos ejecutar de la siguiente manera:

$JAVA_HOME/java -jar [nombre_archivo.jar] [nombre_archivo.xml] [nombre_archivo_salida.sql]

Por el momento lo tengo en una fase inicial y estoy liando con la compatibilidad de algunos tipos datos, dado que DBDesigner te genera archivos orientado principalmente para MySQL por ende esta libre a cualquier critica o sugerencia que me sirva para mejorarla. No tengo todavia un servidor propio asi que lo tengo alojado por aqui
PD: Compilado con JDK 1.5 (5.0)

Desde que decidi utilizar PostgreSQL como gestor de base de datos, me tome el trabajo de ir poco a poco migrando varias de mis pequeñas aplicaciones que las tenias desarrolladas utilizando como gestor a MySQL y bueno como entenderan se me presentaron algunos inconvenientes en la compatibilidad en los tipos de datos. Para eso realize una pequeña tablita en base ha informacion que estube revisando por la web, con los tipos de datos que podriamos utilizar en comparacion uno a otro.

TIPOS DE DATOS
MySQL	PostgreSQL
bigint	bigint
double, decimal, float	numeric
int, mediumint	integer
smallint, tinyint	smallint
char	character
varchar, enum, set	character varying
longtext, mediumtext, text, tinytext	text
tinyblob, blob, mediumblob, longblob	bytea
datetime, timestamp	timestamp
time, date, year	date

Hace poco he estado trabajando con la parte de replicacion en PostgreSQL, y la verdad me parecio no muy complicado trabajarlo con Slony-I, para lo que no conozcan Slony-I, es un sistema de replicacion que soporta conexiones de tipo maestro y multiples esclavos ya sean con conexiones en cascada o fileover (bases de datos en el mismo nivel). Estube revisando por la web algunos manuales con respecto a este tema y me tope con varios de ellos pero me quedo con dos links interesantes, en la cual en una se hace la configuracion sobre Linux y otra sobre windows. Para los interesados.

A solicitud de una compañero de trabajo, me pidio como obtener informacion de las tablas y columnas en una base de datos en PostgreSQL. Bueno aqui lo comento para quien le sea necesario.

Esta sentencia me lista de todos los esquemas existentes de una base de datos: SELECT schema_name FROM information_schema.schemata

Esta sentencia me lista de todos las tablas de un esquema determinado: SELECT table_name FROM information_schema.tables WHERE table_schema =’nombre_de_schema’

Esta sentencia me lista de todos las columnas de una tabla especifica: SELECT column_name FROM information_schema.columns WHERE table_name=’nombre_de_tabla’

Estas pruebas las realize en la version 8.2.4 de PostgreSQL

La verdad que este gestor de Base de Datos tiene muchas cosas interesante que mostrar, en el poco tiempo que lo llevo usando me ha dado buenos frutos y sobre todo que amigos compañeros de estudio y trabajo, usuarios de software propietario se estan convenciendo de las grandes cualidades de este gestor. Hace poco realizamos un pequeño experimento (me retaron jejeje) en la cual realizamos una pruebas con una base de datos de tamaño regular. Para eso teniamos una PC con MsSQL Server (sobre MS Server 2003) y otra con PostgreSQL (sobre Linux Suse 10.1), OJO que las dos maquinas eran solo PC Pentium IV con 1.5 Gb. de RAM y un disco duro de 40 Gb respectivamente. Realizamos la configuracion necesaria en cada gestor y luego tratamos de meterle toda la carga posible ya sea mediante consultas, inserciones, actualizaciones, etc. y la verdad PostgreSQL se portaba mucho mejor y el tiempo de respuesta era menor, claro que estas pruebas no se dieron en condiciones adecuadas como deberia, pero lo mejor es que les gane la apuesta jeje.

En pocas palabras:
“Conserva el alto rendimiento sin sacrificar la estabilidad ni la integridad de los datos, osea simplemente funciona.”

Obtenido de EcuaLug

Uno de los pequeños inconvenientes que se me presento a la hora de usar PostgreSQL, fue el ir migrar mis Store Procedures, los cuales lo tengo en ASE (Adaptive Server Enterprise), esto con la finalidad de utilizar Power Builder para un proyecto que estoy desarrollando (por cuestiones de trabajo) y segun comentarios y experiencias con este gestor; es muy bueno y entonces decidi probarlo. En el proceso de aprendizaje tube que migrar algunos SP y de todas maneras me tube que aprender algo del Lenguaje procedural propio de PostgreSQL (PL/PgSQL) y la verdad me parecio muy interesante y no tan dicifil de manejar. Una forma simple de migrar un SP de ASE a PostgreSQL por ejemplo podriamos hacerlo de la siguiente forma:

Procediemiento Almacenado en ASE:

CREATE PROCEDURE dbo.sp_consult_contrib @tipo char(3), @valor varchar(100) AS BEGIN   if @tipo = ‘RS’   Begin     Select num_ruc From snt$prin_contrib Where nom_rac_soc like @valor+’%’   End Else Begin     Select nom_rac_soc From snt$prin_contrib Where num_ruc = @valor End END

El Mismo Procediemiento en PostgreSQL:

CREATE OR REPLACE FUNCTION sp_consult_contrib(tipo char(3), valor varchar(100)) RETURNS varchar AS $$ DECLARE   ruc char(11);   razon varchar(100); BEGIN   IF tipo = ‘RS’ THEN     Select num_ruc into ruc From snt$prin_contrib Where nom_rac_soc like valor || ‘%’;     RETURN ruc;   ELSE     Select nom_rac_soc into razon From snt$prin_contrib Where num_ruc = valor;     RETURN razon;   END IF; END; $$ LANGUAGE plpgsql;

y la forma de llamarlo desde Power Builder seria mas o menos asi:

string ls_tipo, ls_valor, ls_val_proc ls_tipo = ‘RUC’ ls_valor = ‘20809898121′ select * into :ls_val_proc from sp_consult_contrib(:ls_tipo,:ls_valor); En este caso el valor devuelto se alamacena en ls_val_proc

Ahora estoy de proceso de migracion de otros SP, espero no se me complique la cosa pero asi como vamos me parece que todo va por buen camino