Re: Info sobre diferencias de rendimiento entrepl y sql

On 8/3/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Yoel Mc Lennan escribió:
> > Ok, contemplaba ese tema en las funciones con pequeña o mediana lógica,
> > quizá sea bueno generar las funciones tipicas como insert, update de tablas
> > simples en sql y las que tienen más funcionalidad en pl, el día que cambie
> > de motor (que sinceramente espero que no ocurra seguido), será más simple
> > cambiar el código.
>
> Bueno, la verdad es que da casi lo mismo si las haces en plpgsql o en el
> generador del codigo SQL de la ultima capa de tu aplicacion, porque en
> cualquiera de los dos casos es posible que tengas que reescribirlo :-)

Al menos si le interesa mantener el rendimiento... en mi trabajo
usamos un ERP llamado BaaN, el cual se puede conectar a no se cuantos
motores de bases de datos...

pero para eso tuvieron que inventar su propio SQL y el rendimiento
apesto... entonces crearon "drivers" distintos para cada motor de
bases de datos (supuestamente migraremos a una nueva version que
acepte los nuevos drivers proximamente, veremos cuanto a mejorado)

lo que puedo decir con seguridad es que actualmente un programa de
estadisticas se demora hasta 5min (con clientes grandes, algunos
reportes hay que dejarlos toda la noche) para sacar la informacion...
en cambio con un script en sql puro lo saco en 30seg para el mismo
cliente (tenemos una base INFORMIX)

> Incluso yo diria que es mas portable en la aplicacion, porque si te
> ciñes a SQL estandar es muy posible que funcione sin cambios en Oracle,
> SQL Server, etc (solamente tendrias que cambiarlo en MySQL).
>

en realidad, no me agrada la idea de hacer un sistema "migrable" entre
motores... y en muchos casos no es posible sin complicar demasiado las
cosas, debido a que la mayoria de las bases tienen sus propios
entendimientos de que debe pasar en ciertas casos... por ejemplo; en
ORACLE, NULL = ''

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook