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.

Hace poco estube desarrollando una pequeña aplicación en Mono (Build 1.2.4) el cual trata de conectarse a una base de datos en ASE 15.0(Adaptive Server Enterprise), en base a este codigo pude observar lo siguiente:

… … using Mono.Data.SybaseClient; public static void Main( String[] args) {     connectionString = “Server=SERVER_BD,5000; Database=demo; User ID=sa; Password=;”;     IDbConnection dbcon;     dbcon = new SybaseConnection(connectionString);     dbcon.Open();     ….     ….     ….     dbcon.Close();     dbcon=null; }

nachxs@kimera:~$ mcs r:System.Data.dll -r:Mono.Data.SybaseClient.dll connect.cs

El detalle es en la cadena de conexión “connectionString”. Por ejemplo, hago lo siguiente:

string connectionString = “Server=SERVER_BD,5000; Database=demo; User ID=sa; Password=;”;

Compilo y ejecuto la clase con esta cadena de conexión y me va bien, me muestra la información que necesito. Pero cuando tengo lo siguiente:

string connectionString = “Server=SERVER_BD,5000; Database=bd$demo; User ID=sa; Password=;”;

Me compila bien pero a la hora de ejecutar me aparece lo siguiente:

Unhandled Exception: System.FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list. at System.String.FormatHelper (System.Text.StringBuilder result, IFormatProvider provider, System.String format, System.Object[] args) [0x00000] at System.String.Format (IFormatProvider provider, System.String format, System.Object[] args) [0x00000] at System.String.Format (System.String format, System.Object[] args) [0x00000] at Mono.Data.SybaseClient.SybaseConnection.ChangeDatabase (System.String database) [0x00000] at (wrapper remoting-invoke-with-check) Mono.Data.SybaseClient.SybaseConnection:ChangeDatabase (string) at Mono.Data.SybaseClient.SybaseConnection.Open () [0x00000]

Según lo que se puede observar, no se esta realizando la conexión a la base de datos, al parecer por el carácter “$” que coloque en la cadena de conexión (Database). Esto lo publique en la lista de mono solicitando alguna respuesta, quizas alguno de los que lean este post me puedan dar algun alcanze sobre esto.

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

Despues de haber utilizado MySQL, PostgreSQL y otros manejadores de base de datos, por cuestiones de trabajo se me presento la oportunidad (por no decir la necesidad ) de trabajar con una nueva herramienta en lo que respecta a bases de datos, se llama Adaptive Server Enterprise (ASE) , que es un producto desarrollado por la empresa Sybase. Actualmente la empresa en donde laboro trabaja con ASE sobre Windows Server 2003 y desarrolla sus aplicaciones en Power Builder, la empresa compro las licencias hace un tiempo. ASE es una base de datos relacional de gran potencia que esta mas enfocada a la arquitectura Cliente / Servidor y otras caracteristicas mas que la puedan destacar. La idea de esto es poder usar una version que esta desarrollada para plataformas Linux(la cual si existe), de preferencia para Suse Linux Server Enterprise, Linux Red Hat Enterprise, Turbo Linux y Red Flag, debido a que tiene soporte para dichas plataformas. Solo veremos como nos va y les comentare mas adelante la experiencia.