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.carra...@gmail.com <mailto: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 <mailto: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 <mailto: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
