¡No uses Stored Procedures!

Muchas veces he leido comentarios acerca de el uso de la conexión por JDBC , consultas nativas y SP, creo que es sub utilizar la plataforma que ofrece Java EE y por lo tanto decidi escribir un articulo sobre ese tipo de cosas, realmente copie y pegue en su totalidad el articulo en formato de texto y ademas agrego la url al mismo para que puedan leerlo mejor.

Este es un articulo algo largo que carece de ejemplos técnicos o prácticos pero por el contexto de mi historia se entenderá de el por que nunca los he usado y tampoco necesitado, espero seguir así.

Cuando inicie en el mundo de la programación entre en un curso del CEDIS(Centro para el Desarrollo de la Industria del Software), en el cual al finalizar me consiguieron una entrevista de trabajo para entrar a una consultora y desde allí no paré de trabajar.

En el curso nos hicieron hincapié entre la diferencia de Java y Java EE, como debe ser la arquitectura de una aplicación Java EE, algunos conceptos como WAR, EJB, JSP, JSF, ORM, JPA, HTML, CSS, Javascript y SQL.

Ya dentro de la realización de los requerimientos vimos como mapear, insertar,consultar, actualizar y borrar registros de la base de datos con el Entity Manager.

Modelamos algunas bases de datos relacionales y nos dimos cuenta de la importancia de las relaciones y que cuando llegamos a algún lugar sin salida, apegarnos a las reglas básicas de normalización, simple, pero efectivo.

Al llegar a mi primer trabajo mis mentores, tenían muy buena experiencia y me reafirmaron con practica y fundamentos técnicos lo que había aprendido con la teoría, ademas de algunas otras cosas, me hablaban de JPQL , de por que aveces era necesario utilizar el ORM en lugar de JPA y por que las consultas nativas eran malvadas.

Nunca ejecute una consulta nativa con JDBC creando conexiones a la base de datos de forma programática, siempre obtenía la conexión de un JNDI en el DataSource del servidor y hacia la consulta con JPQL o HQL, hacerlo con JDBC eran muchos problemas y sumarle que es una consulta nativa todavía mas.

Cuando decidí cambiarme de trabajo fui a varias entrevistas, muchas de ellas con tecnologías raras y mezclaban cosas que no deberían ser, algunas consultoras ofrecían muy buenos sueldos, mixtos por supuesto, pero requerían que trabajar con PHP, .Net, PL/SQL, Ruby, Node, Java etc.

Rechace el trabajo y les hice la observación de que eso no era hacer software de calidad, les traería muchos problemas, en su defensa, ellos alegaron trabajar para el gobierno, una razón mas para hablar de política, el gobierno decidía con que... y como..., para mi el usuario/cliente no manda, solo da la dirección, nosotros somos los expertos o deberíamos ser.

Antes de cambiarme contrataron a mi reemplazo y comencé a explicarle en que estaba y que era lo que seguía, las consultas, que versión de Hibernate teníamos, le enseñe el HTML y como utilizando Bootstrap podías maquetar sin una linea de CSS.

No se si realmente me estaba poniendo atención, pero recuerdo muy bien su pregunta.

Yo, realmente no supe que responder y dije , ¿ los que ? , el me respondió muy serio, si , ¿Donde están los Stored ? , yo no sabia que era eso y recurrí, como buen aprendiz, a mi mentor, el cual contesto que nosotros no utilizábamos Stored Procedures.

El me pregunto que como hacíamos para ejecutar las consultas a la base de datos y trate de explicarle en 2 horas que era un ORM, JPQL, las ventajas de su uso, etc.

Me di cuenta de que aunque trabajó con Java, simplemente no sabia que era Java EE.

Fue la primera vez que escuche esa pregunta y después en otras entrevistas de trabajo la volví a escuchar, muchas veces, mas de las que me gustaría.

Quizá con otros lenguajes o plataformas en el desarrollo de software sea valido, en Java EE no.

1

Después platique con muchas personas y la mayoría defendían a capa y espada el uso de los Stored Procedures y por que los ORM's son 200 mili-segundos mas lentos en una consulta.

En ese punto se me ocurrió una pregunta en forma de analogía muy buena que va así.

Un carro irá mas rápido si le quitas los asientos, vidrios y las puertas, ¿Por que no se los quitas?

Lo mismo pasa con el JDBC, una consulta tardara mucho menos ejecutándola con JDBC que con el ORM, pero pierdes la transaccionalidad, el mapeo automático de objetos, el poder agregar un cache, la potabilidad, comprobación de las tablas, los validadores JSR 303, estar expuesto a SQL Injection , entre otras cosas.

La mayoría responde defendiendo que pueden hacer un cache manual, que no necesitan el @Transactional, nunca cambiarán la base de datos y que para que perder tiempo en convertir la consulta a un objeto si pueden retornar un Array de Strings, ¡Válgame Dios!.

Al trabajar con JDBC en solitario, se vuelve un calvario, no existe un orden, la lógica esta en la base de datos con los Stored y se comienza a hacer pequeños pecadillos, como:

No usar los tipos correctos para algunos campos, un ejemplo son las fechas.

Se comienza a evitar el uso de llaves foráneas, es decir si se escribe el campo como tal que hace referencia a X tabla, pero no se crea la llave foránea a la tabla X.

La actualización de registros se vuelve en extremo tediosa y se prefiere borrar el registro y crear uno nuevo, también por lo mismo se evitan las llaves foráneas.

Lo anterior crea un mal modelo de base de datos, el cual no soporta cambios, ya que si borras un campo no sabes a que Stored Procedure le puedes pegar, pues estos solamente mandaran el error en tiempo de ejecución.

A mi no me extraña que no se le tomara importancia a esta funcionalidad de la base de datos hasta la versión de JPA 2.1, pues para que quieres algo que no puedes ver directamente en el proyecto y que puedes hacer lo mismo con una consulta nativa.

Algunas personas me hacen la mención de como le va a hacer si varias aplicaciones tienen que ejecutar el mismo Stored y les contesto que no es necesario.

Solo hay que exponerlo mediante algún servicio y la base de datos debe estar conectada a un único middleware que la controle, de otra forma no será posible tener un cache, utilizar Hibernate Search o alguna otra implementación de Lucene, obvio el Stored se va y en su lugar lo reemplazo con un bonito JPQL, Criteria y nativo en otros casos.

¿ Que tan maduro son los ORM's y JPA ?, tan maduros como los cerros, en Wikipedia nos dice que la primera versión de JPA es del 11 Mayo del 2006, la primera versión de Hibernate, mi ORM de cabecera es del 30 de noviembre del 2001.

En toda mi experiencia laboral, nunca necesite un Stored Procedure, para nada, quizá por que siempre trabajo con Java EE , en Nodejs siempre utilice Mongo DB, pero parece ser que ya existe un ORM que empieza a calar llamado Waterline.

Desconozco si en otros países esto sea algo común, pero en México si lo es, solo vayan a la pagina de Java México y encontrarán ejemplos muy pintorescos de todo lo que estoy escribiendo, sonare muy alarmista en esto pero es horrible darle mantenimiento a proyectos así, no se lo deseo a nadie.

Quiero poner mi granito de arena para que el día de mañana que alguien le toque modificar algún proyecto mio no se encuentre en las situaciones por las que yo pase, espero poder dejarle un proyecto lleno de pruebas unitarias, pruebas e2e , indicadores de calidad mínima,sin código repetido y la infraestructura para comenzar con las DevOps.

No es mi intención dañar a nadie, ya que existen plataformas en las cuales los Stored Procedures encajen perfectamente, pero en Java EE ¡NO! , cuando encuentre el caso técnico valido, actualizare este articulo, pues por ahora lo desconozco completamente.

Si necesitan ayuda u orientación de esto, pueden leer mis artículos anteriores sobre Spring, escribir en los comentarios o mandarme un correo.
Por fin me desahogue xD
Fuentes :

https://en.wikipedia.org/wiki/Hibernate_(framework)

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Nopalin

Pues lo que acabas de

Pues lo que acabas de escribir no es un artículo, es meramente una entrada de blog donde expones los inconvenientes que haz tenido a lo largo de tu carrera profesional. Lo que si es un hecho y que tal vez no mencionas directamente es que muchos ingenieros en sistemas no son programadores, son meramente usuarios de algun IDE o de algun framework, donde si se los quitas estan completamente perdidos.

Yo creo que decir que nunca se usen stored procedures es tan extremista como cualquier fanatismo, los stored procedures siguen siendo utilizados por que dan soluciones a problemas que JavaEE o cualquier otro framework no pueden resolver, si no fuera así no habria tanto soporte para divertos lenguajes dentro de PostgreSQL (por citar un ejemplo). Yo utilizé hibernate por muchos años, y al principio estaba encantado con él (al parecer igual que tú) pero empiezas a tener proyectos más y más complejos y llega un momento en que hibernate no da el ancho. Ahora utilizo Spring JDBC, me desarrolle una pequeña api para construir consultas sql y el código está limpio, no hay peligro de sql-injection y tengo pleno control sobre la base de datos. Algo que omitiste es que incluso con hibernate de vez en cuando debes escribir consultas en SQL (lo que te amarra a la base de datos y su famoso independencia se ve destruida), por que la base de datos tiene una función particular que no la soporta JPQL o HQL y tu la necesitas mucho, luego están los famosos y tediosos mapeos de dto's para que puedas enviar objetos al cliente en lugar de entidades, sin contar con que tienes la dependencia a un servidor de aplicaciones. Debes recordar que las herramientas no son las que te brindan la posibilidad de crear códigos entendibles, escalables y mantenibles, si no que son los programadores, si el programador es malo parecerá que escribió con los pies, si el programador es bueno intentará dejar un código limpi y que sea entendible para alguien más.

Saludos

Imagen de neko069

JPA/Hibernate vs inexperiencia..

Sólo agregaré:

Yo, realmente no supe que responder y dije , ¿ los que ? , el me respondió muy serio, si , ¿Donde están los Stored ? , yo no sabia que era eso y recurrí, como buen aprendiz, a mi mentor, el cual contesto que nosotros no utilizábamos Stored Procedures....

Y luego:

trate de explicarle en 2 horas que era un ORM, JPQL, las ventajas de su uso , etc...

Aparte de:

En toda mi experiencia laboral, nunca necesite un Stored Procedure, para nada, quizá por que siempre trabajo con Java EE....

¿Cómo se puede dar una opinión al respecto, y aún más una comparación desde la inexperiencia?
Y luego todos los argumentos defendiendo y exponiendo a Hibernate como un sustituto completo para ... ¿qué? si no se sabe contra qué se defiende.

Es claro que no puedes hacer ése tipo de comparaciones, y menos si estás en un desarrollo donde se decide no usar un ORM (por cualquier razón) entonces, ¿ahí qué aplica?
¿Se insiste hasta el cansancio en implementar una tecnología que muy probablemente no tenga la necesidad de estar en el proyecto? ¿se hace un
berrinche y se renuncia en vez de aprender a implementar alguna otra herramienta para interacción de base datos (la más común: Spring JDBC) ?
Son muy buenas tus ideas y sugerencias, pero porquerías, con cualquier tecnología y en cualquier lenguaje.

Imagen de gorlok

Te falta recorrer muchos km, pequeño saltamontes.

¿No uses Store Procedures? Jajaja, qué buen chiste. Si en un contexto particular, usar SP es la mejor solución, ¿cómo no los vas a usar? Prácticamente en todos los sistemas donde he participado, y en particular en aquellos donde se usa primariamente JPA/Hibernate, siempre pero siempre también aparecen algunos SP para determinadas tareas.
En general, la primera solución se hace sin SP. O en sistemas triviales, es raro que sea necesario. Pero luego, si hay problemas de performance, o en ciertas tareas muy particulares, a veces es conveniente que algún proceso se realice directamente en la BBDD usando SPs.
También, a veces al hacer interfaces con otros sistemas (Sistemas Oracle Forms por ejemplo, sistemas en otras tecnologías y proveedores, sistemas externos, etc), hay casos donde es conveniente o es la única alternativa interactuar vía SPs. Así como muchas veces se usan Web Services (sean SOAP, REST) para integrar sistemas, también a veces se usan SPs, Vistas, etc.
JPA y los ORM son una tecnología fantástica, que bien usada y con criterio, es adecuada para muchos tipos de problemas. Pero a veces es mejor usar otras tecnologías. Ya sea un NoSQL, Lucene (lo he usado bastante, más que todo a través de Hibernate Search), JDBC plano (mejor con JDBC-Template de Spring o similar), o lo que sea.
El problema es siempre el mismo: si uno solo sabe usar un martillo... va a mirar a todos problemas como si fueran clavos. Pero si uno conoce más herramientas, descubrirá que hay una razón detrás de cada una de ellas. Con la experiencia y cierto criterio, y sin tener miedo de consultarle a gente que sepa más que nosotros, nos irá guiando sobre qué conviene usar para cada caso. Y probar las cosas... tampoco hay que quedarse con la "fe" de lo que otros dicen... porque a veces lo que le funciona a uno, no le sirve a otro, o son consejos sin estar basados en pruebas reales.
Me asusta cuando alguien dice: "no usen tal cosa", que es lo mismo que te digan: "hay que usar tal cosa... es lo mejor y todo ahora se hace con esto". Y yo les digo: "a ver... hagamos una prueba y comparemos. Quien sabe, ya veremos". Los fundamentalismos son para las religiones (y jamás terminan bien), no tienen lugar en las ciencias, Informática incluída ;)

Eso fue en mi primer trabajo

Es dificil encontrar un caso de uso para un SP, hoy normalmente estoy en un lugar donde para todo eran SP's y sigo sin encontrarle una justificacion, mas que para integracion con sistemas antiguos o por que alguien que hace berrinche lo quiere así, es por eso que creo que no es coincidencia que se agregara el soporte a hasta la version 2.1 de JPA .

Es importante recalcar que los problemas de performance siempre tienen que ver con un mal diseño en el proyecto, falta de optimización y mal uso de las herramientas o desconocimiento de ellas.

Porquerias las podemos encontrar de muchas formas, pero hasta en eso existen niveles, no es lo mismo llegar y encontrar una consulta con JPQL que por descuido siempre hace subconsultas por cada elemento en la lista(Un error muy comun debido a una excepcion que tiene que ver con Lazy Load) que una base de datos completa con tablas sin relaciones( Las nombre tablas satelite, por que solo andan volando por allí).

Las herramientas estan allí por algo y Java siempre a tenido el enfoque de ayudar al programador a no equivocarse, solo basta con seguir las especificaciones un poco, ni muy muy ni tan tan , es muy aburrido apegarse completamente a Java EE.

Que uses un ORM no quiere decir que no puedas utilizar los SP , o ¿ si ?, es decir puedes tener tu ORM siguiendo un buen patron de diseño, el mas común en esto es el DAO y listo pones tus consultas en los DAO´s y da igual si es SP,JPQL, criteria, Fulltext , etc , el abanico de herramientas se hace mas grande, un ORM no te limita y puedes seguir disfrutando de JTA y te olvidas de la administracion de las transacciones.

Y si nos ponemos muy revolucionarios, por que esto no es nuevo, un ORM también te da la posibilida de conectarte a una base de datos no relacional.

Si bien , en algun desarrollo se decide no utilizar un ORM , pues es como darte un balazo en el pie, mejor no utilices Java, quiza en algunos casos tampoco Node.js , supongo que el tratar de hacer un sistema agnostico a la base de datos es tan mala que la mayoria de las plataformas trata de tenerlas tambien xD.

También existen alternativas a los ORM's aunque en lo personal no he pasado del "Hola Mundo", creo que es lo que sigue pero aun estoy con los SP's.

Tengo cerca de 5 años de experiencia y aunque se que aun me falta mucho por aprender no te recomendaria por ningun motivo usar los SP, prefiero 100 veces una consulta nativa dentro del código, las cuales estan bien soportadas, lo mejor de Java EE es que tiene bien documentada la parte de la persistencia y cubre la mayoria de los casos, ya es cuestión de cada quien que deuda tecnologica le dejaran a los que les toque dar le mantenimiento a su proyecto, dios me libre.

Un ORM no es un martillo, es una navaja suiza

Un ORM no te limita.

Si tienes problemas de performance lo mas comun es que no se tenga implementado, ni siquiera, el cache de segundo nivel de Hibernate( Hibernate es mi campeon en los ORM's) y que exista un problema lejos del código.

Si vas a interactuar con otros sistemas estan muy de moda los microservicios, aun no sabemos cual es su factura total, y las siempre seguras colas, pero insisto , los SP´s lo unico que se me ocurre donde puedan intervenir son sistemas antiguos en los que consumir un simple servicio web REST sea imposible, no mas.

Para cosas que son procesos largos existen herramientas especificas.

Nunca te recomendaria utilizar JDBC a bajo nivel, tampoco es necesario y aumenta la probabilidad de que te equivoques, si desarrollas una libreria o alguna alternativa a los ORM's quiza si, pero para un sistema de los normalitos de siempre no.

Prefiero decir hoy no uses los SP's y que tenga una repercución en los lectores para que sea su ultima opción antes de proponer una solución, lo ultimo que quiero es que esta tendencia siga presente en México ya que en algun momento puede que heredemos el código a alguien mas y no lo digo por que no quiero que me pase, lo digo por que ya me paso y no se lo deseo a nadie.

Si mencione las consultas nativas

Si mencione las consultas nativas, pero creo que Spring JDBC aun se queda en algo muy basico para proyectos mas complejos y que requieran algo mas de power, es decir, el CRUD ya esta casí por defecto gracias a JPA y los ORM's , solo le das algo de contexto y declaras las interfaces de los repositorios de spring data, si las cosas se complican y con JPQL no alcanza te vas a las consultas dinamicas con criteria de Hibernate, los predicados de los repositorios de spring data te dejan un codigo horrible y aun no los recomendaría por que faltan tutoriales y creo que estan algo verdes, pero alli van, eso si al ser una consulta a tablas que no tienen nada que ver no queda de otra que tirar de lo nativo, no hay opción.

Los DTO's no los usamos, preferi seguir utilizando las entidades marcando como @Transient las propiedades que no quiero que sean columnas y configure el Jackson para que las tome en cuenta al pasar el objeto a JSON, solo hay que jugar un poco con las herramientas y te olvidas de de los DTO´s, como en todo existen excepciones, vi la posibilidad de usar @JsonIgnore pero quiza cuando se presente el caso de usarlo tendira que crear tambien un DTO xD, aun no llega.

En el mundo real la agnosticidad de una base de datos no siempre es 100% , de hecho siempre hago mencion de esto, quiza no sea al 100% pero hay que tratar de dejarla como lo marca la regla de pareto un 80 - 20 , es decir no es lo mismo migrar de base de datos un proyecto que esta 100% en consultas nativas que uno que esta solo 20%.

Si no quieres un servidor de aplicaciones, para eso esta spring boot , tiene un tomcat dentro pero hicieron un buen intento, otra es que puedes utilizar Spark con Spring para ese punto o ya muy extremo metes tu aplicacion en un docker con todo y Tomcat, WildFly o el que te guste mas.

Y si eso lo escribi debido a la mala experiencia con ese tipo de cosas, de alli la advertencia al inicio de la entrada, el problema es que una cosa lleva a la otra, es decir, veia algunas cosas y decia por que se hizo esto asi, lo seguia , lo seguia y encontraba las razones fundamentadas en el uso de la tecnologia.

Algo mas importante que los frameworks son los principios de la ingenieria del software. SOLID

Imagen de neko069

Creo que quieres meter

Creo que quieres meter demasiados temas en algo que es muy específico: SP o no SP ?

Mencionas muchas cosas que no vienen al caso, pero la razón de fondo es que defiendes a capa y espada a Hibernate, cuando tú mismo dices que no haz tenido la necesidad (y por consecuencia, no tienes la experiencia) de usar SP. En mi caso ya he experimentado el crear y consumir SP contra usar Hibernate, y ha sido de todo, casos donde Hibernate puede usarse, casos donde para casos específicos es usar SP aún con Hibernate y casos donde Hibernate es un estorbo.

No tiene nada que ver el NoSQL porque ya se extiende la discusión de más a otro punto que no tiene nada que ver.

Que Java tenga herramientas y que puedas usarlas, no quiere decir que tengas, en todos tus proyectos. Éso no obedece a un análisis previo sino a preferencias y es algo pésimo meter cualquier herramienta sólo por mera preferencia (o ignorancia, o inexperiencia) ante otras alternativas.

Lo mismo al punto de "darse un balazo en el pie" y "no uses Java" tampoco es el punto agregar una herramienta, una capa de abstracción más, un nivel de indirección más si el proyecto no tiene una razón meramente técnica válida.

Con respecto a JOOQ creo que también hay que ponerse a leer más, JOOQ ni siquiera intenta ser un ORM, es un enfoque distinto (y puede usar Hibernate si alguien insiste en meterlo) para interactuar con una base de datos.

Y con respecto a seguir recomendando un ORM sobre un SP, pues nada, espero un caso bien específico, donde muestres técnicamente cómo y porqué Hibernate es una herramienta de uso superior sobre un SP, donde te hayas tomado la molestia de revisar que un SP no basta para tu requerimiento y es necesario (de nuevo, técnicamente hablando) sustituirlo, por una capa de abstracción más; hasta que éso pase todos tus argumentos se derrumban ; y espero que no malentiendas ni lo tomes personal, ataco la idea, no a ti. La idea de imponer algo cuando no se sabe de alternativas.

creo que deberias leer mejor

Nunca dije que JOOQ fuera un ORM xD.

Esto fue lo que escribi:

También existen alternativas a los ORM's aunque en lo personal no he pasado del "Hola Mundo", creo que es lo que sigue pero aun estoy con los SP's.

...

Defiendo el hecho de que en Java EE no es necesario SP's, tiene muchas y mejores herramientas y como te contestaba antes, estoy en un lugar donde todo es con SP's y no le encuentro justificación alguna y el problema no es que los usen o no, el problema principal es lo que va generando que los usen.


No usar los tipos correctos para algunos campos, un ejemplo son las fechas.

Se comienza a evitar el uso de llaves foráneas, es decir si se escribe el campo como tal que hace referencia a X tabla, pero no se crea la llave foránea a la tabla X.

La actualización de registros se vuelve en extremo tediosa y se prefiere borrar el registro y crear uno nuevo, también por lo mismo se evitan las llaves foráneas.

Lo anterior crea un mal modelo de base de datos, el cual no soporta cambios, ya que si borras un campo no sabes a que Stored Procedure le puedes pegar, pues estos solamente mandaran el error en tiempo de ejecución.

A lo anterior le sumamos que ahora rompes el principio de responsabilidad unica, ahora la base de datos procesa la información, cuando su principal funcion es almacenarlos.

Y como bien escribi en el post, cuando encuentre una situación lo actualizare, por lo pronto allí se queda.

No es mi intención dañar a nadie, ya que existen plataformas en las cuales los Stored Procedures encajen perfectamente, pero en Java EE ¡NO! , cuando encuentre el caso técnico valido, actualizare este articulo, pues por ahora lo desconozco completamente.

En conlusión, ¿es posible utilizaros? , si , ¿realmente son necesarios ?, no , ¿En mi opinion personal los recomendaria?, no , ¿Cuando los usaria?, en casos de capricho del cliente o en algo tan extremo que todas las herramientas anteriores mencionadas o una simple consulta nativa no pueda resolver.

Suerte!.

Pura escoria

 

Hay mucha escoria en Internet. Algunas veces, también aquí.

Mucho ruido y pocas nueces

No me sorprende que aquí en México se trate de defender su uso y mas de uno se ponga a rezar, se tire al piso y rude para apagarse el fuego y correr como gallina sin cabeza xD , realmente no se de donde salio esa practica tan arraigada, la pude ver en empresas refresqueras, pasteleras, logistica, bancos, etc.

Como lo puse a modo de advertencia en mi publicación, al igual que lo explico en el mismo, existe una cultura de utilizar ese recurso
cuando no es necesario y se defiende su uso con justificaciones al estilo ¿como puedes decir eso?, a mi siempre me han funcionado, en algunos casos no hay otra solución y tienes que usarlos, siempre existen excepciones.

La unica razón en lo personal por la que se me ocurre que se deba utilizar es en la integración con algun sistema tan viejo que solo entienda de SP's, no mas, justifiquen su uso por cosas que realmente tengan peso.

Para mi se queda corto en funcionalidades y manejos de errores, si tienen algun caso practico podemos analizarlo
y ver por que decidieron usar SP y que otra solución podria aportarle yo en mi humilde experiencia, vamos que en esto de programación existen muchas soluciones y todas funcionaran, pero es no quiere decir que esten bien(deuda tecnologica).

Comentar algo que realmente aporte tecnicamente y enumerar los pros y contras de cada solución, es muy sencillo decir pura escoria y no aportar nada en los comentarios, entonces el comentario se vuelve escoria.

Publica el problema y lo resolvemos.

Imagen de neko069

Intentas devolver la pregunta

Intentas devolver la pregunta que te hice en tu post inmediato anterior:

Publica el problema y lo resolvemos.

Cuando yo fui el primero que te dijo,que precisamente publiques algo que ya hayas resuelto. No sé de donde sacas que:

No me sorprende que aquí en México se trate de defender su uso ... blablabla...

De nuevo, no he leído algo concreto y aún más especulaciones y suposiciones, y más cuando hablas de recomendaciones. Al parecer no eres mexicano, o no haz trabajado en proyectos en México, si me equivoco sería mejor un ejemplo concreto de qué problema tuviste y cómo lo resolviste .

Si en tu primer post escribiste, que cuando resuelvas un problema lo publicarás, entonces creo que el sentido del post se pierde, sólo por la razón de que no tienes nada contra qué comparar.

De nuevo, mientras no haya un punto de comparación, en concreto, todo me suena a que es algo que debe estar porque sí y todas las tecnologías que estén en un proyecto deben tener una razón técnica bien fundamentada .

En fin la discusión se vuelve tediosa, y que conste, no defiendo el uso de SP, mucho menos de Hibernate, defiendo las decisiones tomadas bajo estricto análisis, no porque alguien venga y me diga que X es mejor que Y, y que cuando le pregunte el porqué me quiera marear con muchos argumentos pero sin un caso de éxito concreto.

Cuando actualices el post, con un caso técnico, una liga a un proyecto en Github o algún repositorio con sus test respectivos, con código que probar en alguna base de datos de tu elección, y se vea de forma contundente que en cualquier caso de uso Hibernate sea superior a un SP, entonces puedes tener algo de credibilidad.

Saludos.

La pregunta la hice yo primero en el post xD

Como dice el titulo la pregunta la hice yo primero, alli esta bien clarito en el post, pero creo que hare otro post de cuando no usar SP's.

Si soy mexicano, pero también estuve en proyectos donde los lideres son extranjeros, nunca usamos SP's, ni siquiera se mencionaban.

La idea de dejar links y de mas cosas es que las personas que lo lean puedan investigar mas lejos de lo que dice el post y formen un criterio propio, solo trato de dejar una regla general, por que como en todo, las herramientas importan , pero importa mas el contexto.

Este es el primer caso practico:
Tengo un proyecto en github donde allí no existe el uso de SP's, es una lista de pendientes muy simple, sin login, sin seguridad, aun sin cache y
que es algo comun altas bajas y cambios, sin SP's, forkealo y cambialo por SP's.

Supongo que será el primer caso de cuando no usarlos.

Saludos.

Re: Publica el problema y lo resolvemos.

 

¿De qué problema hablas? Si hubo un problema alguna vez (relacionado con TI, ¡por supuesto!), ya está resuelto, sea que utilice SPs o no. ¿O qué? ¿No puedes?  

~~~

Estoy de acuerdo contigo jesusperales

Llevo casi 10 años de experiencia y nunca he tenido la necesidad de resolver algo utilizando SP. He recibido o heredado algunos proyectos que mandan a ejecutar SP, he tenido la necesidad de darle soporte y mantenimiento, y siempre que he podido los he migrado a algún servicio o método Java. He intentado mantener ese desacoplamiento entre componentes, donde a la BD le toca almacenar, catalogar y ordenar los datos, en la medida de lo posible trato de no procesar o tener lógica de negocio en la BD, me parece mas fácil de soportar y mantener.

Hay que tomar las publicaciones como opiniones personales, nadie tiene la verdad absoluta.

Re: Estoy de acuerdo contigo jesusperales

 

Estoy de acuerdo contigo jesusperales ...

¡Ja, ja, ja! ¡Debe ser una broma! ¡Ja, ja, ja!

~~~

jpaul No te pongas celosa

También estoy de acuerdo contigo, aunque no aportaste mucho en el debate del post, mas que servir de Troll.

No terminé de leer todos los comentarios

No terminé de leer todos los comentarios, pero creo saber de que va esto. Hay personas que se niegan adoptar una nueva tecnología, les da miedo el cambio. Yo he podido migrar de JDBC a Hibernate a JPA. Y no regreso atrás.
Es verdad, las primeras versions de Hibernate y JPA eran horribles, muchos archivos xml para mapear correctamente, pero ahora con los POJOS y anotaciones todo fluye de manera simple, haciendo un uso extenso del concepto Convención sobre configuración y ahorrandonos mucho mucho tiempo de desarrollo.

Aquí una reflexión mía y de algunos autores