Re: Duda con procedimientos almacenados.

From: Francisco Javier Morosini Eguren <francisco(dot)morosini(at)gmail(dot)com>
To: postgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Duda con procedimientos almacenados.
Date: 2014-08-24 01:45:00
Message-ID: CABofrE06rxQbB8kyYtBDnzvRT9os6YaP5hER5XWWuui8cc3XZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

en el mundo real lo mejor es meter la logica de negocios en la DB,
especialmente si es postgres, por un tema de escalabilidad y performance,
creeme, hibernate es bloatead, recargado y muy pesado, ademas los calculos
en sp son muy faciles de programar, ya existe un depurador para postgres en
el pgadmin, muy bueno, eso de la portabilidad no es real, si usas postgres,
para que vas a portar a oracle? o a mysql? o a SQL Server?, eso de
aplicaciones portables en base de datos es fantasia, antes quizas, un
oracle / postgresql, pero si tu aplicacion es muy portable no sera
suficientemente rapida pues delegaras mucha funcionalidad a la aplicacion,
lo cual en si ya es lento, por ejemplo las secuencias en las tablas, si lo
haces portable ahi ya tienes un problema real en alta carga.

saludos

2014-08-23 18:33 GMT-05:00 Hellmuth Vargas <hivs77(at)gmail(dot)com>:

> Hola Lista
>
> Las consideraciones son las siguientes
>
> - lógica de negocio en la base de datos.
>
> Pros: el desempeño, pues no hay que trasladar los datos a la aplicación
> para realizar las operaciones y cálculos requeridos, todo se realizan
> 'locales' en la base de datos y la aplicación se convierte básicamente solo
> presentación, ademas los framework como Hibernate tiene el inconveniente
> que que generan código, o mas bien sentencias, sub optimas lo que también
> afecta desempeño e incluso sobrecargan la base de datos.
>
> Pros: PostgreSQL soporta actualmente una gran gama de Lenguajes (PL/java,
> PL/Python, PL/Ruby, etc) que permiten diseñar los procedimientos con altos
> niveles de mantenimiento y aplicando patrones de diseño y Programación
> Orientada a Objetos, entre otros paradigmas de desarrollo.
>
> Contra: Portabilidad, si desarrolla aplicaciones para diferentes clientes
> con bases de datos heterogéneas, lo mejor es trasladar la lógica de
> negocio a nivel de aplicación y trabajar con Hibernate que solo con
> archivos de configuración puede cambiar el léxico a la base de datos
> seleccionada.
>
>
>
>
>
>
>
> El 23 de agosto de 2014, 13:09, Mario Jiménez Carrasco<
> mario(dot)carrasco(at)gmail(dot)com> escribió:
>
> Gracias por el aporte Fede....
>>
>> En efecto, ese fue un tema por el cual optamos por meter el codigo de
>> logica de negocio en la aplicación, por la posibilidad de que los clientes
>> quisieran migrar de base de datos...
>>
>> Sin embargo, el cliente actual comenta y justifica su necesidad de mover
>> los procesos a procedimientos almacenados en el hecho de que el servidor de
>> base de datos debe cargar con todo el procesamiento y liberar de esa
>> ejecución al servidor de aplicaciones...
>>
>> Hemos tratado de explicarle y justificarle que aun estando la logica de
>> negocio en la aplicación el proceso de consultas lo lleva a cabo el motor
>> de la base de datos, pero no conseguimos convencerlo, por ello ando
>> buscando documentación u opiniones para poder tener los elementos
>> suficientes...
>>
>> o algun tipo de pruebas de benchmarks que se pudieran ejecutar?...
>>
>> Gracias..
>>
>> Saludos...
>>
>> Atte. Mario Jiménez Carrasco.
>>
>>
>> 2014-08-23 13:03 GMT-05:00 Fede Martinez <federicoemartinez(at)gmail(dot)com>:
>>
>>> En mi experiencia, el codigo en stored procedures es mas dificil de
>>> extender, modificar y demas. Hay herramientas que un lenguaje como java te
>>> da (herencia, polimorfismo, etc) que no tenes con stored procedures. Tenes
>>> mas herramientas para testing, etc.
>>>
>>> Por otro lado, si usas stored procedures. Perdes la posibilidad de pasar
>>> a otro motor de bases de datos el dia de mañana, no se si es un posible
>>> escenario para vos no.
>>>
>>> Igualmente, esto es solo basado en mi experiencia personal. Si vas a
>>> hacer la migracion asegurate de tener una buena base de testing para que
>>> puedas tener seguridad de que el codigo nuevo funciona igual.
>>> El 23/08/2014 14:53, "Mario Jiménez Carrasco" <mario(dot)carrasco(at)gmail(dot)com>
>>> escribió:
>>>
>>> Buen día amigos...
>>>> Espero este sea el medio adecuado para obtener ayuda sobre la duda que
>>>> tengo...
>>>>
>>>> Estoy desarrollando una aplicación en JAVA usando Hibernate y
>>>> PostgreSQL, tengo algunos procesos de lógica de negocio que estan en la
>>>> capa de servicios de la aplicación...
>>>>
>>>> Hace algunos días me comentaron sobre la idea de migrar la lógica a
>>>> procedimientos almacenados en la base de datos...
>>>>
>>>> Mi duda es: ¿Que tan recomendable sería hacer dicha migración?.. o en
>>>> su caso, ¿Qué consideraciones debería tomar en cuanta para determinar si
>>>> debo llevar a cabo la migración?...
>>>>
>>>> He buscado información en la lista sin encontrar mucho respecto a este
>>>> punto para la toma de decisión, si alguien puede ayudarme orientándome o en
>>>> su caso darme referencias para lectura, se agradece de antemano...
>>>>
>>>> Saludos...
>>>>
>>>>
>>>> Atte. Mario Jiménez Carrasco.
>>>>
>>>
>>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> PostgreSQL DBA
>
>

--
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Martín Marqués 2014-08-24 02:05:10 Re: Duda sobre uso de pgbouncer
Previous Message Yoan Manuel Pérez Piñero 2014-08-24 01:11:47 Duda sobre uso de pgbouncer