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.carra...@gmail.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 <federicoemarti...@gmail.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.carra...@gmail.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
