Re: Duda con procedimientos almacenados.

On 24/08/14 01:33, Hellmuth Vargas wrote:
> 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.
Si bien es cierto que en general el rendimiento puede mejorar porque
efectivamente los datos no deben transmitirse por la red para procesado,
hay dos factores fundamentales que no se deben perder de vista:

- El proceso de programación en servidor es mucho menos ágil. No hay las
mismas herramientas, entornos, facilidad de debugging, etc, para el
desarrollo. Luego hay un balance rendimiento / tiempo de desarrollo que
no hay que olvidar.

- Otro aún más importante es que la bbdd escala mucho más difícilmente
que otras capas que pueden ser stateless, como un servidor de
aplicaciones. Entonces, tener la lógica en el servidor de aplicaciones
para procesados pesados (que no involucren excesiva carga de red) puede
tener mucho sentido.

Esto no contradice nada de lo anterior, sólo aporta balances
complementarios.
>
> 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.
Totalmente de acuerdo, sin embargo cuidad con el rendimiento. No
todos estos lenguajes ni en todas circunstancias son buenos en rendimiento.
>
> 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.

Al margen de lo comentado, una recomendación muy fuerte: si vas a
reescribir la aplicación o parte de ella, aprovecha para quitar
hibernate. Es en la mayor parte de los casos que he visto la mayor
fuente de problemas, especialmente de rendimiento, en pilas
Postgres/java, además de que no te permite aprovechar el gran potencial
del SQL avanzado de postgres, que hibernate no soporta. Mira en su lugar
jooq.org.

Saludos,

Álvaro

>
>
>
>
>
>
>
> El 23 de agosto de 2014, 13:09, Mario Jiménez
> Carrasco<mario(dot)carrasco(at)gmail(dot)com <mailto: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 <mailto: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 <mailto: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
>