¡No uses Stored Procedures!

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

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.

¿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 ;)

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 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, 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

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.

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!.

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

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.

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.

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.

¿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?  

~~~

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.

Estoy de acuerdo contigo jesusperales ...

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

~~~

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, 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