Re: Info sobre diferencias de rendimiento entre pl y sql

Patricio, gracias por la abundante información , en realidad es precisamente
la estructura que estamos realizando, diseñamos un estandar de trabajo para
nuestras aplicaciones , en 5 capas y 6 en algúnos casos, sean o no
corporativas ya que desarrollamos nuestro propio generador de código, por
ahora compatible con Enterpryse Library por lo que el motor de base de datos
está casi resuelto, en la etapa de creación del generador de funciones
simples y tipicas como Update, delete, insert, etc, me encontré con esta
duda que en realidad solo apunta a saber si se pierde performance al elejir
sql en vez de pl teniendo en cuenta la cantidad de datos a manejar.

Muchas gracias por el aporte, afianza aún más nuestra elección de
arquitectura.
Saludos cordiales
Yoel Mc Lennan

----- Original Message -----
From: "Patricio Cifuentes Ithal" <pcifuentes(at)siigsa(dot)cl>
To: "'Yoel Mc Lennan'" <listas(at)yoel(dot)com(dot)ar>; <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Friday, August 03, 2007 11:19 AM
Subject: RE: [pgsql-es-ayuda] Info sobre diferencias de rendimiento entre pl
y sql

Creo q puedo estar saliéndome con un carril muy transverso, pero también a
la vez puede ser un aporte, si no simplemente un OT.
Debes tener en cuenta q en parte de tu comentario, estas pensando en una
solución corporativa, ante eso debe haber un grueso análisis de ingeniería
en el nivel de desarrollo, y esto tiene mucha importancia con un tema de
capas de estas mismas, para no tener un problema como el q muestras en
términos de SQL o PL, puede que lo recomendado y teórico funcione bien,
bajo ese aspecto "Teórico"... pero en la practica puede ser un parto
extremo. Explicare como un pequeño desarrollo de análisis de capas de
ingeniera que esta mas q aprobado, probado y puede ayudar en algunas
inconveniencias como la expuesta aquí.

Partiendo por la base de MVC (Modelo Vista Controlador), la gestión de un
proyecto de ingeniería de software, dice que debieran haber mas capas que
estas tres, ya q estas son básicas. En ese punto se debe agregar la
escalabilidad y la portabilidad, (lo siguiente puede sonar a crítica pero
mas q eso es un aporte)

Todo eso tiene que ver con el negocio en donde esta inmersa la institución
a quien se le va a desarrollar. Por lo tanto, ya tienes un ambiente de
negocio. Para esto debes definir reglas generales del negocio y en base a
eso definir en donde irán tus reglas especificas del negocio en el
desarrollo del software del proyecto. En lo teórico algunas Universidades e
Instituciones y varias paginas web he visto que esto debe ir si no siempre,
casi siempre en la capa de fuente de datos, o sea en el motor de base de
datos (modelo), esto implica hacer Store Procedure y demaces. Pero
pregúntense por un minuto. Si quieren migrar a otro motor?, si se quiere
actualizar el motor?, me ha pasado fuertemente que he realizado Store
Procedure en postgres con direcciones a directorios con sentencias
especificas y varias cosas mas, y al querer hacer una actualización, llámese
escalabilidad y/o portabilidad dentro del mismo motor, he tenido variados
inconvenientes, de comandos nuevos de mas parámetros en funciones internas
del motor, las librerías no son las mismas.. etc. Por lo tanto esos puntos
de portabilidad y escalabilidad se van casi por el suelo, si no te pones a
leer la doc. especializada del motor de BD. Y te conviertes en un
especialista mas del motor de BD, y muchas veces el tiempo apremia y no se
puede, y contratar un especialista puede estar ligado a salidas de
presupuesto del proyecto.

En este caso he resuelto un modelo de N capas, la mas básica q tengo en
términos de plataforma web es de 5 capas, pero existen mas si se requiere
desglosar.

1 vista (plantillas)

2 controlador (lenguaje)

3 reglas de negocio (este es el punto en donde quiero llegar, de preferencia
hacer las reglas de negocio en clases dentro del lenguaje, por lo tanto se
desarrolla una sola vez y permite tener la escalabilidad a cualquier otro
lenguaje de programación orientado a objeto, las clases son clases aquí y en
la quebrada del ají, la escalabilidad de este nivel es mas fácil que en
niveles de mas abajo, por documentación (UML ayuda bastante), por que es mas
fácil encontrar especialistas en lenguajes de programación que especialistas
en un determinado motor de BD por lo tanto si se necesita migrar el lenguaje
o plataforma lo cual es menos requerido (por experiencia), ya q mayormente
siempre se pide cambiar la fuente de datos(motor de BD), siempre será mas
fácil migrar las reglas de negocio en las clases que en los Store Procedure.
En términos generales en las clases se crean los string de SQL y
comunicación con la fuente de datos a través de un controlador de la capa 4,
recuerden hacer los string SQL según las ANSI's por q si en el caso deben
hacer portabilidad a otra BD, los SQL estarán creados de forma estándar y no
tendrán inconvenientes en comandos que existe en un motor y no en otro).

4 Acceso y Gestor (bueno esto mayormente visto como el ADO, pgpool,
ADODBforphp, bueno lo q elija cualquiera para poder conectarse a su BD (esto
permite parte de la portabilidad, tanto en la capa 2 y 3 como en la 5))

5 Fuente de Datos (mil y una vez postgres... después Oracle, SQL server y
demaces...). recuerden q en esta etapa los motores de BD deben cumplir con
el ACID y algunos ANSI´s como postgres jejeje...

Uufff.. me canse... En resumen, si tienes problemas en los Store Procedure
por la portabilidad o escalabilidad de las BD puedes hacer el quite a esto
simplemente programando en clases las mismas reglas de negocio, pero en un
nivel mas alto.

Ojala haya quedado claro y si hay alguna critica constructiva, opiniones,
puntos de vista, felicitaciones (jeje), aportes, bienvenida será.

Patricio Cifuentes Ithal
Ingeniero en Informática

SIIGSA
www.siigsa.cl
56-2 204 60 22

> -----Mensaje original-----
> De: pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:pgsql-es-ayuda-
> owner(at)postgresql(dot)org] En nombre de Yoel Mc Lennan
> Enviado el: viernes, 03 de agosto de 2007 09:38
> Para: pgsql-es-ayuda(at)postgresql(dot)org
> Asunto: [pgsql-es-ayuda] Info sobre diferencias de rendimiento entre pl
> y sql
>
> Hola lista, eastoy implementando una solución corporativa y me
> encuentro
> con una duda , sería bueno escuchar comentarios o ver material al
> respecto.
>
> Las funciones se están escribiendo en pl, pero ante la posibilidad de
> migrar
> la base en un futuro a otros proveedores MSSQL, Oracle, etc (más allá
> de las
> bentajas o no de cada una ) creo entender que sería más simple tener
> todo en
> SQL y no en PL, pero la verdad aun no he podido testear performance de
> una u
> otra como para evaluar la opción.
> se trata de cerca de 500 funciones por lo que no es algo para pasar por
> alto
> y los registros a manejar por tabla serán de 500mil a 1 millon, si bien
> los
> informes y cálculos no superarán los 5000 registros .
>
> Desde ya muchas gracias por el aporte.
>
> Saludos
> Yoel Mc Lennan
>
> ----- Original Message -----
> From: "Sebastián Villalba" <sebastian(at)fcm(dot)unc(dot)edu(dot)ar>
> To: "Gabriel Hermes Colina Zambra" <hermeszambra(at)yahoo(dot)com>; "Dilm
> E.I.R.L"
> <i(dot)dilm(at)yahoo(dot)es>; <pgsql-es-ayuda(at)postgresql(dot)org>
> Sent: Friday, August 03, 2007 8:41 AM
> Subject: Re: [pgsql-es-ayuda] Nuevo en PostgreSQL
>
>
> Hola a todos...
>
> On Thu, 2 Aug 2007 23:31:58 -0500 (CDT), Gabriel Hermes Colina Zambra
> wrote
> > El tercer punto era el uso del ODBC, yo no uso
> > powerbuild, pero uso ado con Visual Basic, o con
> > Visual Interdev, asi que lo uso, los que usan .net
> > usualmente usan nplsql, tema en que no puedo ayudarte.
>
> Una simple corrección al buen aporte de Gabriel. El driver para
> trabajar con
> Visual Studio .NET (me parece que es así el nombre correcto, pero puedo
> estar
> equivocado) es "npgsql"[1]. Saludos...
>
> [1]: http://gborg.postgresql.org/project/npgsql/projdisplay.php
>
> -
> -------------------------------------------
> Sebastián Villalba
> sebastian(at)fcm(dot)unc(dot)edu(dot)ar
> -------------------------------------------
>
> --
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda
>
> --
> ---------------------------(fin del mensaje)---------------------------
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>
> --
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
>
> www.siigsa.cl

--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

www.siigsa.cl