Javatadas

MySQL vs PostGreSQL vs Oracle

Y con este ya seguro que me gano abucheos, críticas, e incluso insultos de los más fanáticos de Oracle.

Sin entrar en la seguridad y estabilidad de Oracle, de sobra conocida por todos...(aunque tengo entendido que cuando Oracle se cae, se cae de verdad). ¿Alguien se atreve a decir algo sobre la performance de Orace?

En nuestro sistema hemos hecho una prueba muy simple. Una tabla con 3 millones de registros (catastro de rustica). Pido 500.000 (los quiero dibujar en un mapa). Lo hago con MySQL, PostGIS (extension de PostgreSQL con tipos espaciales) y Oracle. La consulta es la misma y todas las tablas tienen índices. MySQL y PostGIS apalizan a Oracle. Y Oracle está en modo "sin log de transacciones". Entre los dos primeros, gana MySQL también con cierta diferencia.Sí, ya sé, que haga tunning. Yo solo pongo ahí el dato (tampoco hice tunning de los otros dos). Sí, ya sé. Oracle tiene tablas transaccionales. Las otras creo que ya también. Pero vamos, yo solo quería un mapa. Cuando alguna de las otras me pete en mita de una transacción supongo que me cagXXX en XXXX!&$·"!!

(2004-03-26 20:07:38.0) Permalink Comentarios [17]

Programación Orientada a la Base de Datos (Matizando)

Por si de mi anterior post se deduce que menosprecio a los programadores de entornos Oracle/Forms, me gustaría hacer algunas matizaciones.

En primer lugar, decir que cada entorno tiene sus peculiaridades, y su forma de trabajar. Yo solo decía que los desarrolladores que cambiaban a entornos Java arrastraban muchísimos vícios.

Uno de estos vicios es desarrollar en Java sin utilizar una de las potencias del lenguaje: la orientación a objetos. Un error común es poner toda la lógica en la base de datos en forma de PL/SQL, y hacer las Widgets con Swing. Exactamente la forma de trabajar con Forms.

A continuación, y supongo que será solo una opinión, pienso que el núcleo de una aplicación empresarial debe ser desarrollado en un lenguaje de programación de propósito general.

En mi corta carrera profesional (solo llevo 4 años)he atravesado por migraciones de la base de datos en las dos. En una fue de Empress (os suena a alguno? es viejo, pero corre que se las pega) a Oracle. Ahora de Oracle a MySQL. Estas migraciones no se plantean porque sí. Surge la necesidad, y se hace. Se analizaron las ventajas de Java (en entornos multiplataforma, con estaciones de trabajo Sun pa qué decirlas). Es más, en algunos casos han dado servicio las dos bases de datos simultáneamente (un sistema viejo de captura de datos seguía en explotación y trabajaba con Empress, y un nuevo sistema que estaba en fase de implantación trabajaba con Oracle. Todos los días se hacían volcados de Empress a Oracle).

Tampoco es infrecuente ver ofertas pidiendo gente experta en Java y en Natural/Adabas (¿Los hay?) para trabajar en migraciones. Este no es mi ejemplo. Mi ejemplo es el de un sistema que siempre tiraba contra Oracle (muchos clientes / un servidor), bien de forma directa bien con Middleware, y por una necesidad puntual, el uso de MySQL en portatiles suponía un ahorro de licencias. MySQL no era el objetivo, ha sido una solución para un problema concreto. Pero no cargar la lógica en la BBDD permitió esta salida.

Esta opinión no quita que todo dependa de los cambios que se prevean, y de la flexibilidad que se desee obtener. Supongo que nadie se compra Oracle pensando que va a usar MySQL a los 6 meses. En el caso de un sistema GIS, nosotros pretendimos conseguir un producto genérico, soportado por un modelo de objetos que nos permitiese tener clientes Desktop y a la vez construir servidores de datos.

Uno de los objetivos era la total independencia del almacenamiento persistente de los datos. ¿Por qué? En el mundo GIS no es infrecuente que te llegue un fichero procedente de una toma de datos en campo, y que se te pida mostrarlo cartográficamente. Esto implica que el sistema lea datos lo mismo de un fichero que de una base de datos o de un servidor middleware.
Por ultimo, una opinión muy partidista (jeje, esto levantará ampollas): QUÉ FEO Y ANTIESTÉTICO ES EL CÓDIGO ESCRITO EN PL/SQL...;)

(2004-03-26 19:52:26.0) Permalink Comentarios [1]

Programación Orientada a la Base de Datos vs JAVA y Sw Libre

No se trata de una evolución o revolución de la POO.
En mi empresa hay un gran capital humano que trabaja con Oracle, Forms, PL/SQL, etc.
Algunos están siendo reubicados,sin ningún tipo de formación :( ,a entornos Java. No es mi intención criticar uno u otro entorno. Muchos son excelentes profesionales, y ante el arte que tienen del SQL no puedo más que quitarme el sombrero -se las ingenian para hacer QUERYs asombrosas-.
El problema es que traen vicios heredados del entorno anterior, que no tiene nada que ver. Uno muy concreto es el de la programación orientada a BBDD. Todo lo quieren hacer con PL/SQL, y para ellos Java es un Front/End más dificil de usar que Forms.
A mí, particularmente, no me gusta meter logica en la base de datos. En nuestros sistemas la base de datos es un sitio donde guardamos y/o recuperamos objetos.
Podemos entrar en las ventajas o desventajas de esta política, pero yo prefiero dar algunos datos:

• La independencia de la plataforma de Java nos ha permitido desarrollar un mismo servidor de objetos del que tenemos dos instancias levantadas. Una en una maquina bajo Windows, porque tiene que servir imagenes raster de elevada compresión ECW. Este formato es propietario :( y solo se puede leer con una DLL que proporciona el propietario de la patente. Nuestro servidor la invoca vía JNI. El mismo servidor proporciona el resto de datos cartográficos en una máquina Solaris.
• Nuestros sistemas de producción funcionan bajo Oracle. No obstante, son independientes de él: nuestras clases de negocio están separadas del acceso a datos mediante la aplícación del patrón DAO. Este año la JJAA va a lanzar una campaña de recogida de información de todos los propietarios agricultores -no puedo decir más- mediante visita puerta a puerta, con encuestadores provistos de portatiles con nuestro sistema GIS. ¿Sabeis lo que cuestan 100 o 200 licencias de Oracle? La solución estará basada en MySQL. Coste: analizar el soporte de datos espaciales de MySQL y hacer un DAO para nuestro sistema.

¿Os imaginais si nuestra aplicación hubiera estado hecha en PL/SQL? La Junta se va a ahorrar cientos de millones en licencias gracias a Java , el Software Libre, y el patrón de diseño DAO que hace que un sistema no solo funcione en Oracle...

(2004-03-26 10:56:21.0) Permalink Comentarios [2]