Re: Duda con procedimientos almacenados.

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