¿Deberías usar PROCEDIMIENTOS ALMACENADOS? - #3 Dilemas de un desarrollador

En la actualidad, ¿deberías usar procedimientos almacenados en la base de datos? Te cuento mi opinión en este nuevo video de la serie "Dilemas de un desarrollador"
MIS CURSOS
📐 Arquitectura de Software: manuelzapata.c...
🔌 Patrones de Diseño: manuelzapata.c...
📦 Programación Profesional con Objetos (Gratis): manuelzapata.c...
🌲 Principios de Diseño SOLID (Gratis): manuelzapata.c...
🙌 Hazte miembro del canal: / @manuelzapata
🌎 Mi sitio web: manuelzapata.co
🎦 Suscríbete al canal: manuelzapata.c...
📩 Mi lista de correo: manuelzapata.c...
#ManuelZapata #Procedimientos #DilemasDesarrollador

[@RockdrigoSchen]

Estoy usando Procedimientos almacenados por 2 razones. 1. hago cálculos complejos de varios miles de registros por día y al realizar dichos cálculos en la misma BD evito tener que pasar datos por las redes mejorando el rendimiento. 2. Hay funciones que se están usando en distintos lenguajes, por ejemplo, un sistema web hecho en un lenguaje que hace un ingreso de mercadería hace las mismas tareas que otro sistema que es una app, entonces con esto evito tener duplicar código en ambos sistemas, escribo las funciones en la BD y las llamo desde los distintos lenguajes asegurando que en ambos casos harán exactamente lo mismo. Me facilita la mantención también ya que si debo hacer un cambio lo hago en la BD y listo.

[@orlandovera3344]

Eso es muy razonable, comparto la logica cuidando el rendimiento, una mejor practica es delegar la responsabilidad al ambito donde se genera, en virtud de mantener el encapsulamiento, la alta cohesion y bajo acoplamiento, es la filosofia de GRASP - Experto

[@wilsonpachito5722]

Totalmente de acuerdo con Rodrigo

[@edustreamimg]

Desconocía la penalización en las conexiones a bd desde php a sqlserver con lo cual habían procesos que funcionaban correctamente cuando eran bd pequeñas (hasta 8 GB) después de esto vi que todos esos procesos empezaban a embotellarse porque no es lo mismo hacer un group by sobre una tabla de 1 millon de registros con sus joins que con una de 18 millones aparte de los otros sub-informes que se mostraban en el dash. La empresa no tenía presupuesto para adicionar ni un módulo de RAM al servidor que era lo que veía que pasaba, se ponía a tirar de paginación. Despues de optimizar las tablas consultas claves etc etc el rendimiento mejoro levemente pero no era suficiente. No había programado nunca proc almacenados, pero si había escuchado que cada conexión a la bd (cada consulta) creaba una latencia. Me animé a probar migrar parte de esta lógica de php a un p.a. cual fue mi sorpresa? Que de un informe que tardaba casi 30 segundos con php y sqlserver con el p.a no llegaba ni a medio segundo y no daba problemas de memoria ni time-out. A partir de entonces siempre que veo que alguna consulta se me atasca por muy optimizada que esté la llevo a un p.a.

[@ManuelZapata]

Interesantísima esa experiencia que comentas, Eduardo! Gracias por compartirla.

[@DiegoRFGonz88]

aca la clave son los roundtrips es decir cada hit que le hace el backend a la BD, hay una latencia para la comunicacion entre el back y bd, a no ser que los tengas en un mismo servidor lo cual no todos lo hacen. Cada consulta tiene milisegundos y suman, si hago una transaccion donde hago 4 consultas, 3 updates, 2 deletes y 2 inserts, son 11 hits y sumados todos dan una latencia ya considerable, ahora multiplicalo por la cantidad de usuarios y transacciones, tener tu logica en la BD haces solo 1 roundtrip

[@wilsonpachito5722]

Excelente, eso es una delicia trabajar con P.A en casos complejos

[@smillvasquez1117]

En el caso de EF, se utilizan store procedures por temas de rendimiento.

[@ManuelZapata]

Cierto! El rendimiento ha sido un criterio fuerte para usar stored procedures.

[@rurouniize]

@@ManuelZapata Tal vez en algún momento, en donde trabajo teníamos procesos almacenados para trabajar con la actualización y movimiento de información... lamentablemente el rendimiento de este era muy pobre, tardaba más de 3 horas en movilizar 26k de registros, por lo que a modo de prueba se reescribió el mismo procedimiento almacenado en código de la aplicación y vaya sorpresa pues el procedimiento a realizar ahora solo demoraba 30 minutos. La lección aprendida fue, no siempre es posible tener todo en procedimientos almacenados sobre todo que estos llamen a más funciones en el interior. Finalmente hemos ido cambiando poco a poco de procedimientos almacenados a código en la aplicación y uso de consultas, lo que nos ha ayudado a mejorar el rendimiento y velocidad de ejecución.

[@CeleChaudary]

@@rurouniize A nosotros nos pasó un caso similar y lo único que hicimos fue usar "WITH RECOMPILE" y aumentó la velocidad en que el SP procesaba la información... De igual manera me alegro que estén pasando la lógica a código de aplicación, prefiero eso que tener lógica en los SPs y tener SPs que llaman a otros más...

[@rurouniize]

@@CeleChaudary interesante, podría ser aplicable. Aunque actualmente ya llevamos dos años desde el cambio

[@CeleChaudary]

@@rurouniize Como se sienten con el cambio? Fue para bien o para mal?

[@alyssabuensuceso3733]

En mi caso, yo dejaba en procedimientos almacenados las consultas para reportes ya que se volvió molesto recompilar el código y publicar nuevamente las páginas que hacían esas consultas o servicios que hacían uso de esas consultas; llegó a ser más fácil modificar las consultas ya que en ocasiones, algún cliente quería cambios en sus reportes. Prefiero que en la base de datos se dejen los códigos para los inserts, updates, deletes y selects ya sea que se deban guardar datos en una o varias tablas solo recibiendo los parámetros necesarios, en vez de ejecutar todos esos códigos desde la aplicación como he visto lo hacen en PHP. El Entity Framework me ha parecido bueno, pero aún me falta más práctica, pero creo puede ayudar mucho también; pero por mis experiencias previas aún me causa ruido el aplicarlo.

[@ManuelZapata]

Gracias por tu aporte, Alyssa! Ciertamente, para reportes con consultas complejas, los procedimientos almacenados facilitan el trabajo. En cuanto al código en base de datos para hacer CRUD, tiene el reto de que sea usado efectivamente para eso, y no que termine poniendose la lógica de negocio ahí. Y sí, un ORM como Entity Framework definitivamente reduce la fricción al trabajar con bases de datos. Por cierto, tengo un video sobre ese tema: kzbin.info/www/bejne/Z4KmoKBqbdGqZrs

[@fvillanuevanet]

Actualmente uso procedimientos únicamente para reportes, ya que manejo un reporting services y para reportes complejos me funciona muy bien.

[@gussware4177]

INSISTO manuel zapata TIENES QUE HACER CURSOS EN UDEMY PAGO LO QUE SEA POR TALLERES PRÁCTICOS DE TODO LO QUE HABLAS

[@ManuelZapata]

Por ahora tengo un par de cursos en mi propia plataforma. Echales un ojito: Curso de patrones de arquitectura: manuelzapata.co/curso-practico-patrones-de-arquitectura/ Curso de patrones de diseño: manuelzapata.co/curso-practico-patrones-de-diseno/ Te agradezco la recomendación. Saludos Guss!

[@devrub623]

@@ManuelZapata udemy

[@ManuelZapata]

@@devrub623 No descarto Udemy en un futuro, pero la verdad es que no me gusta.

[@viktorbravo9255]

Antes no usaba programación en la base de datos, empece a usarlos por que al delegar procesos a la db mis módulos se volvieron mas ágiles, puedes resolver muchas cosas desde la db sin necesidad de volver a compilar y distribuir, por seguridad solo esperas parámetros de determinado tamaño. La desventaja que le encontrado es la que mencionas, el código que esta en la base de datos y cuando migras es fácil olvidarlo

[@ManuelZapata]

Interesante tu escenario! Creo que es bueno mencionar que a pesar de que sea código en la base de datos, igual hay que versionarlo y desplegarlo. Gracias por tu aporte Viktor!

[@Bc7-w9k]

@@ManuelZapata y como lo versionas Manuel, yo creo un archivo sql en mi repositorio y lo voy modificando , o eso está mal??? o es anticuado

[@borisgr04]

Yo lo hacía pero el control de versiones lo siento muy complejo. Me voy por los objetos. Mejor testing. Lo puedes automatizar. Las operaciones en memoria de objetos son más rápidas. Lo digo basado en experiencia.

[@viktorbravo9255]

@@borisgr04 Reciente empecé a repasar Android y llegue al tema de la base de datos, en esta parte haces un versionado y control mediante un clase. Entonces se me ocurrió hacer lo mismo con una capa extra MantenimientoDB, por ejemplo creas una tabla que tenga tabla persona que tiene Id, nombre y teléfono, luego por alguna situación le tiene que agregar otro campo, dirección digamos. En tu clase tienes la versión 1 que dice que ejecutes un "create if not exist table persona..." en tu version 2 se haria una evaluación si ya cuentas con el campo dirección y si no aplicar un "alter table..." de manera similar se haría con los procedimiento almacenados, de esta forma se respalda en el mismo código y tendrias un "versionado" de la db y los sp. De esa manera puedes tienes una app que hace el mantenimiento y me ha funcionado cuando tengo tengo cambios en la db de desarrollo y tengo que pasarlos a producción. Otra cosa que debes de tomar en cuenta es que tan compleja o cambiante va a ser tu query, si solo es un simple select de una tabla, en lo personal me ha causado mas problemas hacer el sp, pero me ha salvado la vida en el caso de las estadísticas, gráficas y cuando tienes que recompilar muchos datos que al momento no sabes si los vas usar, pero con la retro del cliente los acotas y lo realizas en el sp.

[@yeissonvl]

pero el problema que planteas es no usar un repositorio para los sp funciones y seeds.

[@oscarresendizespinoz]

yo soy mas del pensamiento de usar procedimientos almacenados por varias razones. 1.- cuando manejas muchos datos, al estar yendo por ellos generas trafico innecesario en la red. 2.- Si haces un cambio en la loica de negocio, solo modificas el procedimiento y automáticamente se ve reflejado en todos los clientes ya que de lo contrario tendrías que volver a instalar las aplicaciones a todos los clientes. 3.- Tienes mas control sobre la información y en la forma de que se deben de tratar ya que los clientes solo se limita a llamar a un procedimiento almacenado que algún experto hizo y sabe como debe de tratarse esa información. 4.- Aumentas la velocidad de procesamiento ya que al tener los datos y la lógica en el mismo servidor, no pierdes tiempo en esperar a que los datos te lleguen. 5.- Puedes usar maquinas mucho menos potentes en los clientes que simplemente van a servir para mostrar la información . De los puntos malos el mas importante que yo veo es la dependencia de la base de datos al momento de querer migrar a otro motor de base de datos.

[@Bc7-w9k]

hace algunos meses estaría completamente de acuerdo con tu comentario, y el punto 2 era el que más me gustaba por su utilidad, solo debía cambiar una función en la BBDD y ya, de maravilla. Pero el gran problema es cuando tienes varios ambientes de trabajo, en mi caso, tenemos 3 ambientes, si el cliente pide varias modificaciones a un software ya entregado, entonces tienes que irte al ambiente de desarrollo y hacer las modificaciones, y tienes que mapear todas las modificaciones(procedimientos almacenados) que haces para poder pasarlo a los demás ambientes, cosa que con el tiempo , he sabido hacerlo de manera ordenada y automática. Pero no creerás la cantidad de veces que yo y muchos novatos en sus inicios hicieron cambios en la BBDD de desarrollo y pasó el tiempo y se tuvo que pasar a QA o producción y prácticamente nadie documentó los cambios, en verdad es un dolor de cabeza encontrar los cambios que se hicieron. Este, para mí, es el mayor problema, cosa que con un ORM no pasaría, ya que sería cuestión de pasar la rama por todos los ambientes de trabajo. Igual me gustó mucho tui respuesta, yo tbm he escrito mucha lógica de negocio en Postgrest , pero es hora de cambiar, creo yo, Saludos desde Perú.

[@oscarresendizespinoz]

@@Bc7-w9k si en mi trabajo también tenemos 3 ambientes (desarrollo, QA y producción) y varios servidores con varias bases de datos. y las aplicaciones también las tenemos en nuestras 3 ramas y el proceso es que primero hacemos cambios en desarrollo (tanto aplicaciones como procedimientos almacenados) después un tester prueba en QA y una vez que todo funciona correctamente lo pasamos a producción. Aquí el punto clave es la organización y aunque no nos guste, la documentación. Pero aveces es difícil documentar ya que te enfocas en hacer la modificación y mueves varios Sps al mismo tiempo y no nos damos el tiempo de documentarlo y cuando terminamos ya no sabemos que fue lo que modificamos. Cuando eso me paso en otro trabajo lo que hice fue hacer una aplicación que me buscaba las diferencias en bases de datos y entonces ya sabia de forma fácil que cambios aplicar sin necesidad de documentar.

[@orionx5822]

@@oscarresendizespinoz que aplicación usaste para ver las diferencias ?

[@omarrosas5524]

@@oscarresendizespinoz hola amigo. Yo puedo tener una BD en Postgres con ORM..? Es eso lo que quieres decir también. Gracias.

[@oscarresendizespinoz]

@@orionx5822 una que yo hice. le paso la conexión de ambas bases de datos y comienza a comparar tabla por tabla, sp por sp, triger por triger, vista por vista y me dice las diferencias

[@paulotineomoreno6795]

En un ERP, todos los procesos son complejos, donde necesitas consultar a cada rato a tablas para evaluar cosas, y a la vez insertas a cada rato a diferentes tablas porque es un sistema integrado, con un ORM hacer todo eso, realizar llamadas a cada rato, golpeando al sevidor de bd, ORM yo lo veo para aplicaciones pequeñas donde solo insertas una tabla de mantenimiento. Prefiero mil veces sp.

[@ManuelZapata]

Gracias por compartir tu opinión, Paulo. Usar un ORM tiene sus retos, pero realmente se puede llevar a aplicaciones grandes, sin ningun problema. Si el tema de los llamados constantes se vuelve un problema, se pueden implementar mecanismo de caché. Saludos!

[@FancoCastillo]

Gusto de saludarlo. Hay un factor que está por fuera y de gran importancia, hace 20 años , o digamos un poco menos, gobernaban los sistemas CLIENTE/SERVIDOR, y el tema de los SP, se gestaba más que todo por factores de rendimiento, ya que teníamos la limitación en estos sistemas de la comunicación en la WAN, por lo tanto, imposible por ejemplo generar una actualización a una tabla en un servidor "remoto" con protocolos ODBC , super lento, claro super útil los SP, y luego WS etc.

[@ManuelZapata]

🤔 Excelente aporte Franco! Muchas gracias por compartirlo.

[@OGarciaGarcia]

Estas cracy: 1.-Los procedimientos almacenados ayudan muchísimo a aligerar la carga de lado cliente. 2.- Programas menos código en la App., lo cual la hace más ligera 3.- Facilita las actualizaciones 4.- Ideal para hacer reportes personalizados, etc, etc, etc.

[@alfonsoevangelista9356]

Totalmente de acuerdo con tu enfoque. Es mucho trabajo migrar una base de datos y es especialmente por los procedimientos y funciones.

[@ManuelZapata]

🙌

[@aucancelacarlos]

Excelente tema!! Yo he usado por muchos años sps y me han ayudado de gran manera, sin embargo los orm facilitan muchas cosas. Los dos aportan mucho el reto es saberlos usar en el punto adecuado. Saludos.

[@ManuelZapata]

Exacto! De eso se trata, Carlos. Saber en qué momento se les puede sacar mayor valor a cada uno. Saludos!

[@JuanVernaza]

Excelente explicación, confirme que como estamos trabajando en mi equipo lo estamos haciendo correctamente, aveces llegaban las dudas pero han sido despejadas, ORM full a excepción de consultas complejas. Muchas Gracias.

[@ManuelZapata]

Con todo gusto Juan! Me alegra que te haya servido el vídeo.

[@JosePachecoDeveloper]

Y las consultas complejas podrian quedarse en el ORM si estan bien indexadas las tablas, no estan fragmentadas y si ameritan estar particionadas. Estas consultas complejas pueden estar en Vistas Materializadas inclusive, pero cumpliendo con un buen plan de ejecucion e invocarlas desde ORM via query nativo. O sea, se mantiene la responsabilidad de la logica en el codigo

[@manuelvargasg5377]

Muchas gracias, tenía inquietud en relación a ese tema y con este video me fue resuelta.

[@ManuelZapata]

Genial tocayo!

[@JaimeCedeño-i8n]

Y que piensas en usar jdbi o dapper? Que son como una alternativa al orm.

[@nilsonvargas8658]

Excelente video, no voy ni por la mitad, y considero que explica todo de buena manera

[@ManuelZapata]

Gracias Nilson 🙌

[@joellozano-TurboMarketing]

siempre he tenido ese dilema y ademas me preguntaba si era una cuarta capa o entraba en la capa de persistencia o en la de negocios. No sabia que hoy en diaya casi no se usa base de datos. Hoy en dia la seguimos usando en sistemas bancarios. Me pregunto empresas mundiales como facebook, amazon,etc usabn store procedures. El uso de sp relentiza los procesos?

[@JoseFunez-yu8xm]

Gracias por la explicación, no sabía el significado de PL SQL, entender que es un lenguaje para bases de datos Oracle me ayudará a tener un mejor entendimiento de todo lo que se puede llegar a hacer.

[@mgbeltranb]

De acuerdo en algunos puntos pero en desacuerdo en otros, los procedimientos jamás deberían aplicar lógica de negocio, su rol fundamentalmente debería ser optimizar y medir uso, asegurar transaccionalidad a nivel de motor y aplicar una capa de seguridad extra en caso de ser necesario. Es un debate que llevamos un buen rato con los DBA, al final para un programador es muchísimo mas sencillo usar un ORM y ya está, pero sumergiéndose un poco no resulta tan trivial el cuento. Saludos y gracias nuevamente por tus aportes.

[@ManuelZapata]

Efectivamente, el tema no es trivial! Es interesante ver cómo la experiencia previa de quien toma la decisión, es la que a la larga determina la elección (así una opción parezca mejor que otra). Gracias por tu aporte Mauricio!

[@vancebrennan7668]

you all probably dont give a damn but does anybody know of a trick to log back into an instagram account..? I was dumb forgot the password. I love any tricks you can give me!

[@angelokaiden7196]

@Vance Brennan instablaster ;)

[@orlandovera3344]

Hola Manuel has tratado un tema muy interesante realmennte un gran dilema aclarado a nivel de motor de base de datos, en este caso relacional, al momento no se si en otros tipos de base de datos existen Procedimientos Almacenados, en este caso particular debemos echar mano de conocimientos de telematica por las diferentes latencias de tramas y paquetes en la transmision sobre redes WAN, he notado que estamos volviendo a la filosofia en que los sistemas de datos eran estructurados y pasivos donde todo el trabajo se hacia en codigo, recuerdo los xBase empotrados (dBase, Clipper,FoxBase,) con lenguajes Fortran y C, hoy en dia vemos ese mismo criterio con las nuevas bases de datos no estructuradas orientadas a documentos, clave-valor, etc

[@Coderoll]

Yo siempre he evitado la logica de negocio en la bd, pero uso los sp's para consultas que requieren rapidez p.e. paginación y common table expression. Saludos!

[@ManuelZapata]

Parece que tienes un buen balance para definir que va en la base de datos y que va a nivel de aplicación. A la larga, eso puede ser más importante. El problema muchas veces está en que se no se tienen claras esas reglas de juego y las personas terminan poniendo el código donde mejor les parece.

De acuerdo mucho con la posicion de Manuel, la bd hoy en dia deberia ser solo para almacenar datos, eso si, que el motor es muy capaz de muchas cosas esta bien, pero el hecho de que pueda no quiere decir que deba, y para finalizar mi opinion, si es mejor el PA por rendimiento por ejemplo, peeeero, me he topado con muchos escenarios donde por la logica confusa que hay, se decantan por un PA para no desenredar el caso y seguir adelante con el requerimiento, es decir,d ejando deuda tecnica, entonces con esto quiero decir, que una bd bien hecha, normalizada, gestionada, va ha hacer casi igual de rendidora procesar la informacion en la aplicacion que en un PA, aunque si el trafico de red va a existir, pero no es razon de peso para decantarse por PA, hoy dia tenemos muuucho ancho de banda para este tipo de datos.

[@EdsonFerOropeza]

La mayoría de los proyectos en la empresa se han desarrollado aplicando la lógica en la Base de datos, utilizando procedimientos almacenados, vistas, y triggers, para optimizar esa parte del desarrollo sean creado herramientas propias, como generadores de código SQL, eso nos permite tener el control desde la Base de Datos, y hace que nuestras API REST sean más flexibles en el desarrollo, para poder implementar cualquier tecnología posible del lado del Front.

[@ManuelZapata]

Interesante Edson. Me gusta mucho conocer la experiencia de otras personas. Tengo curiosidad: ¿por qué tener la lógica en la BD les ha permitido tener APIs REST más flexibles? Saludos.

[@EdsonFerOropeza]

@@ManuelZapata Si, sobre todo porque en el equipo podemos hacer pruebas en cualquier lenguaje ya sea en GO, Node.js, o PHP para las APIS. Además la mayoría de las consultas son muy avanzadas y se requiere del uso de procedimientos y cursores, y al tener la lógica en la BD podemos usar cualquier tecnología sin modificar la lógica del proyecto.

[@jairohv]

Pero porque cambiar de tecnología a cada rato. No sería mas práctico tener toda la lógica de negocio en una web service que se comunique con tu bd cosa que solo vas dando mantenimiento a esa web service. Desde el punto de mantenimiento no me convence los procedimientos almacenados ya que no se si se pueden usar patrones de diseño ahí. Aun que tu experiencia me sorprende. Gracias por compartirla

[@cpaez2000]

@edsonfervo16mx Hasta que veo un comentario coherente, aplicado a las actualizacion y necesidades de operacion. Y sobre todo en base a la experiencia. La mayoria de las personas opinan mal de cierta tecnologia porque no la conocen y se casan solo con lo que conocen.

[@jorgeherrera6895]

@@EdsonFerOropeza Esta es la razon numero uno para seguir usando SP

[@xanderjims]

cordial saludo, muchas gracias por los videos. En mi caso yo vengo del mundo de las Bases de datos relacionales, manejo de información y reportes; para mí las consultas más complejas que por lo general se emplean para analizar de grandes volúmenes de datos prefiero hacerlas directamente en la BD aprovechando sus recursos y optimizando el código de la consulta; en mi experiencia muchas veces se cree que hacer una consulta es escribir un SELECT * FROM y se olvidan de entender el modelo ER de la BD. En la practica empleo los ORM para sentencias tipo DML simples, si requiero de información de varias tablas prefiero hacerlo directamente en la BD. Saludos!!

[@ManuelZapata]

Ese me parece un muy buen balance, Alexander. Gracias por compartir tu enfoque. Saludos!

[@josepablomacias1009]

Los procedimientos almacenados es una herramienta, si no sabes usarla esta bien pero no la critiques. El usarla agrega seguridad y consistencia y hasta creo que rendimiento.

[@ManuelZapata]

He tenido la oportunidad de trabajar con procedimientos en Oracle, Postgres y SQL Server. Y entiendo el valor que brindan como herramienta, sobre todo en la época en que nacieron. Considero que hoy en día hay mejores soluciones para los problemas que resuelven. Si así te funcionan, y entienden qué desventajas traen, está bien. No hay lío con eso. Por cierto, tuvimos un debate buenísimo en el canal sobre el tema: kzbin.info/www/bejne/eJS6aIJojs9qfZY

[@josepablomacias1009]

​@@ManuelZapata Con las herramientas te refieres a Orm? Creo que la unica razón para usar un Orm es cuando no sabes de bases de datos.

[@cpaez2000]

@@josepablomacias1009 Exacto!!!...Alguno programadores como no saben de base de datos..usan el ORM como Golden Hammer para solucionar TODA la logica del negocio. Tremendo error porque el ORM es solo para ENTIDADES!!...cosa que no entienden. Todo lo quieren mapear a objetos mapeando todo a Entidades!!.

[@yeissonvl]

lo que dice aplica para proyectos grandes. en un proyecto mas austero. o sea habla sobre la teoria. para saber teoría leo un libro. en la práctica puede tener mucho sentido. por ejemplo no tener que desarrollar un panel administrativo o sea todo es relativo

[@aphipex]

Hay un tema que no se ha tocado ni en el vídeo ni en los comentarios, es el tema del testing, no veo como automatizar este proceso que no implique una serie de riesgos que básicamente no termine en un proceso poco fiable y de alta complejidad, como dices hay herramientas muy avanzadas que facilitan los procesos que se resuelven con SP, de hecho un sistema de vistas de tablas y un orm sería más fiable, administrable, testeable, y automatizable que un SP que básicamente estaria rompiendo el principio de única responsabilidad el cual esta más que comprobado en sus beneficios, eso sí no quiero cerrarme en otros puntos de vista y quiero dar el beneficio de la duda, pero he sufrido mucho por las faltas de test en especial lo unitarios que no iniciaría un proyecto nuevo sin ellos, como la experiencia no sé improvisa, quiero escuchar puntos de vista desde otras perspectivas de gente con obviamente más experiencia, dónde trabajen con SP y con test

[@ManuelZapata]

Ese punto de las pruebas unitarias es super importante. A nivel de aplicación, los frameworks y herramientas están muy maduros en ese aspectos. No sé como se hagan pruebas de SP. Buen aporte @aphipex. Saludos!

[@hectorcasellaspena2]

lo bueno de las SPs en SQL SERVER es que manejan la transacción, es decir puedes afectar N tablas y si se cae un script puedes hacer rollback. Así te aseguras que todo quedó bien. Lo malo de esto, es que las tablas quedan tomadas y producen bloqueos.

[@RubenCortezBrito]

En lo personal creo que depende de la funcionalidad que debe de tener el procedimiento almacenado y por otro lado, si se compra una licencia de Oracle o de Sql Server es para utilizar todas las herramientas que nos proporcionan.

[@leonardopaz2525]

Claro que hay que usarlos es ma facil y optimo el matenimiento de un sistema, cuando el negocio esta en la capa web huff que mamera el mantenimiento y soporte fuera de eso si depliega con docker y toda esa historia de hoy en dia huff yo recomiendo los almacenado un soporte o mantenimiento de un sistema cuando esta en almacenados es de minutos cuando esta la capa web pasas horas para actualizarle al cliente

[@niggeljkd]

ok y como seria en el caso de los triggers,si necesito hacer una accion en un momento dado que se mueva cierta tabla de la base de datos,tambien se puede escrbir desde el codigo de la aplicacion? lo digo por que trataste un tema muy interezante con referencia a migrar bases de datos y tener que reutilizar codigos que esten fuera de la cracion de la base de datos y sus tablas un saludo cordial

[@trex3612]

Exclente ... Explicacion me has despejado muchas dudas... Please haz un vídeo sobre Codeigniter y MVC y dónde debe ir el dominio, encontré errores de poner lógica de negocio en un proyecto heredado y me toca refccionar todo Javascript

[@leviatanMX]

Yo nunca eh usado SP, ya que cuando desarrolle en PowerBuilder, habia una opcion de crear objetos que podias poner en un servidor de transacciones, y ahi en mismo codigo PB podias programar todo el manejo y afectacion de datos, asi que cualquier cambio se hacia en el Transaction Server y no tenias que actualizar cada cliente (PC), y ahora que desarrollo en otros lenguajes, hago lo mismo, en el caso de WEB, al estar el codigo en el servidor, pues aprovecho y lo hago en C# en mi caso, y no utilizo los SP...

[@Bc7-w9k]

excelente video mi bro, recién descubre el canal.

[@ManuelZapata]

Genial Brallan. Bienvenido por estos lados!

[@adolfovanegas7802]

Yo los he usado poco, solo los uso para consultas complejas o pesadas jamas para Crud. Ahora con EF sigo usandolos porque me r3sulta mas facil armar una consulta compleja que con LinQ.

[@cristiancamilosanchezardil9730]

En la base de datos he desarrollado particiones en tablas y crontabs para automatizar creacion de las particiones, pero de resto me gusta interactuar mas con la bases de datos desde la aplicacion con los ORMs , ando con el orm de django, pero quiero ir a go} Gracias por tus consejos!!!!!!!!!!!!

[@edchadev]

Hola @Manuel muchas gracias por estos aportes, podrías hacer un video que explique como los lenguajes orientado a objetos facilitan sustituir los procedimientos almacenados?

[@ManuelZapata]

Interesante tema. Gracias por la sugerencia @EdchaSw

[@rodrigochm74]

@@ManuelZapata Hola, si sería interesante conocer como reemplazar los stored procedures. Saludos.

[@ziskador]

Me sumo

[@Losquepasaremoselsemestre]

8:26 ¿Qué puede ser un caso de uso y qué no? Pasa que en mi grupo de desarrollo en una materia de la universidad estamos tomando como caso de uso a los objetos que requieran un CRUD por decir una tabla Empleado o una tabla Farmacia, cada uno con sus respectivos atributos.

[@YurlyAndresVelezBedoya]

La cuestión es si esta de moda o no, más bien es si conviene y ayuda a agilizar el desarrollo y el rendimiento.

[@MikelDavid]

Interesante, el punto 4 me hizo pensar. Tengo algunos store procedure voy a cambiarlo a aplicación. Una consulta si hay validaciones complejas ahí creo que si vale la pena usarlos. Gracias por la sugerencia.

[@KkeKkaoer]

Que tal Manuel, verás con tantos comentarios si que me he puesto a analizar la situación (espero y me puedas contestar, ya que necesito ayuda de un profesional), bien pues actualmente estoy desarrollando una aplicación web, y precisamente me encuentro en este dilema, actualmente estoy trabajando con el framework Codeigniter, framework que brinda flexibilidad a la hora de desarrollar, pues bien, mi dilema es el siguiente. A mi siempre me ha gustado y siempre he sido de la idea de que cada cosa tiene su lugar, y con la programación no es la excepción, en anteriores sistemas lo he manejado así, el código SQL se queda en la BD y la lógica de negocio y programación se queda en la aplicación, por lo que entonces para cada aplicación, siempre he realizado sus respectivos CRUD Strored Procedures en la BD y en la aplicación, diras, que carajo, este man trabaja doble, pero deja me explico. Si existe una entidad u objeto en mi aplicación llamado EMPLEADO (y su homólogo en la BD por supuesto), y este requiera en su objeto algún otro elemento, como una cartera de clientes activos por decir algo, entonces existirá un SP que se llame getCarteraClientes(), donde reciba como parámetro el ID del empleado y solo se haga la consulta con ese ID, de forma que por el lado de la aplicación solo habrá que hacer un CALL getCarteraClientes(), y procesar esa info de ese lado, así igual con las vistas y demás cosas, por lo tanto, mis SP solo cumplen un rol, que es separar ese pedazo de SQL (que siendo sincero, nunca me ha gustado ver codigo SQL embebido dentro de una aplicación), de la aplicacion, recordando que si existiese una lógica de negocio para poder llamar algún SP, SIEMPRE será procesada previamente por la aplicacion. Mi pregunta es, ¿Que tan correcto o tan operativo es este proceso en base a lo comentado en tu video?, porque, por un lado, existe la ventaja de que del lado de la aplicación solo se necesita de llamar a los SP correspondientes y ellos se encargarán del trabajo CRUD, además de que se que mis procesos de datos se encuentran ahí, de tal manera que si hubiera un error, sabría más fácil donde solucionarle, llamémoslo, un tipo de encapsulamiento, además de la capa de seguridad extra como se mencionó en otros comentarios. Peroooo (siempre hay uno 😒 jajajaja) en desventaja, hay que conocer cuáles son y en cierta parte sería trabajo doble, además de que cualquier ORM puede hacer ese tipo de transacciones SQL, es decir CRUD, y siendo sincero, estaría desaprovechando un mucho su potencialidad al reescribir código tantas veces. Por lo que heme aquí, tratando de resolver mis dudas existenciales, quien sabe, a lo mejor y en un futuro me hago un framework con mi proceso jajajaja, espero y puedas ayudarme, te lo agradecería enormemente.

[@FernandoZamudioC]

Parcialmente de acuerdo, efectivamente antes todo se hacia con procedimientos almacenados era la práctica, ahora entornos como ASP MVC trabajan divociados de la base de datos, no le importa q base de datos hay porq a traves de LINQ un metod universal y al final el se encarga de hacer lo propio para conectarse de forma transparente con SQL Server, MySQL o lo q venga, cambiando una linea (obviamente si todo esta bien hecho), el migra de una base de datos a otra solo con cambiar una linea, SI MUY BONITO pero como ice Oscar mas abajo, hay ciertos escenarios con ciertas momento como por ejemplo manejar muchisisima data sale mejor usar Procedimientos almacenados, OJO un punto medio es perfecto, para hacer el CRUD o sea Crear almacenar modificar BIEN hagalo con su lenguaje nativo PERO para operaciones costosas en performance o de altiima complejidad use Procedimientos almacenados, es mentira que TOOOOOODAAAA la aplicacion esta llena de PROCESOS MEGA COMPLEJOS asi q un termino medio esta bien...

[@NicoILeone]

Muy buena información, justo hablaba de esto con un colega hace unos días. Muy bien explicado, ya tienes un nuevo suscriptor. Saludos!

[@ManuelZapata]

Bienvenido a la comunidad Nicolás!

[@fvillanuevanet]

Excelente video, ya desde hace dos años uso la base de datos como un repositorio de datos y me ha ido bien.

[@ManuelZapata]

Excelente Fidel!

[@anthonymlop]

Vale la pena aprender en profundidad los procedimientos almacenados? Y cuál es su destino de estás.

[@wanchuchos]

consulta, yo hago lo siguiete, mis SP, retorna toda la data directamente en JSON para evitar conversiones y demás por el backend, eso me funciona mejor en rendimiento, pero , está bien ello?

[@selvin_medina]

Me enseñaron que lo mejor es crear los procedimientos almacenados por cada operacion CRUD, y ahora noto que es trabajo extra, mas por que hay que mapearlo en ef, y en estos momentos que estoy con ef core ya es mas, por que aunque sean sencillos los CRUDs hay que estar interactuando con la base de datos y saber si se hizo bien, pasar el valor de retorno hasta llegar al cliente...

[@ManuelZapata]

Muy buen punto. Gracias por tu aporte Selvin!

[@selvin_medina]

@@ManuelZapata Muchas gracias!!

[@carlosmauriciorebolledosie6286]

Tengo que darle mantenimiento a sistemas legados y es un tremendo dolor de cabeza. Toda la lógica de negocio la tienen en transact sql

[@ManuelZapata]

Sí, era una práctica común en sistemas legacy

[@wilsonpachito5722]

Creo que si los procedimientos almacenados ya no aportan nada y ya no vale la pena usarlos, entonces los creadores de estos motores de bases de datos los hubiesen eliminado hace rato como hacen otras tecnologías con funcionalidades...pero si todavía esta funcionalidad existe, es por que para muchos es la solución mas optima a un sin numero de problemas complejos y difíciles de solucionar con cualquier lenguaje de programación del lado del backend

[@elgatosoft]

Tenemos clientes que exigen que gran parte de la logica se maneje a nivel de la base de datos, pues para ellos es mas facil controlarla, entenderla y adaptarla (con los riesgos que eso trae para las partes).... Pero una buena razón por la que la utilizamos (ya en otro contexto) es porque nos permite expandir la funcionalidad de la aplicación, permitiendo que como parte de los procesos, se ejecuten procedimeintos almacenados con calculos específicos programados por cada cliente.... Pero en general, no apoyo la utilización de SPs por loq ue dices de la división de la lógica de negocio

[@ManuelZapata]

Ahí la pregunta es: que ventaja te da un SP para expandir la funcionalidad? Sin tener el contexto de tu caso, pensaría que es algo que también podrías hacer a nivel de aplicación.

[@luisenriquelagosamaya4420]

Cada una de estas estructuras tiene su uso especifico Por ejemplo para rebajar el stock de un producto yo utilizo funciones escalares debido a que solo un valor voy a devolver y es necesario ya que las compras de productos en una empresa grande ocupan muchas peticiones. Los sp sirven para mostrar informacion compleja y de agrupamiento profundo Los triggers para cuestiones de auditoria y acciones de estado No se debe descartar esta tecnologia solo porque se ponen de modas otras Ejemplo : GraphQL Para haraganes sirve eso

[@ManuelZapata]

Mencionas un punto importante: cada tecnología tiene su lugar y espacio. Algo moderno no necesariamente reemplaza lo viejo.

[@mikehurtado4772]

Comparado conmigo eres nueva guardia

[@almatute]

En la actualidad los ORM no son muy eficientes cuando se tiene que trabajar con una BD que maneja unos cuantos millones de registros. Yo dejaría a los ORM para las tareas CRUD muy simples, para el resto de casos usaría store procedure por ser más eficientes. Recuerda que el ORM debe traerse toda la data o parcial de la BD relacional hacia su modelo de objetos, éso es transparente para el usuario pero dicha tarea se realiza y genera un problema de performance.

[@ManuelZapata]

Gracias por tu aporte, Alex. En la medida que los datos crecen, necesitas configurar cosas adicionales en los ORMs como lazy loading, caché y otros.

[@orlandovera3344]

Exactamente, en pruebas de desempeño con miles y milones de registros, el ORM es mas lento, mejor un JSON o Bytes puros

[@Coderos]

Excelente aportación como siempre. Un abrazo Manuel.

[@ManuelZapata]

Gracias Chris!!

[@KarakalLatino]

Bueeeeeno @Manuel Zapata ahora si me quedé mas confundido después de leer todos los comentarios, yo siempre he escuchado que es mejor usar SP, tanto por la seguridad como el desempeño o rapidez de la aplicación...En conclusión que recomiendan hoy abril 2020 para el desarrollo de un ERP de Escritorio, desarrollado en C# con SQL Server y que en un corto tiempo se migrara a la web con .Net Core...Iluminarme please.

[@ManuelZapata]

Como has podido ver en los comentarios, muchas personas prefieren los SP. Mi recomendación es que los evites. Toda la lógica de negocio la puedes manejar perfectamente en C#. Saludos!

[@irancho2]

@@ManuelZapata Estoy de acuerdo contigo manuel, considero la programación de lógica en un SP como una trampa, te da la impresión de ser mas versátil pero a la larga pagas un gran precio por ello, por ejemplo el no poder aplicar buenas prácticas de programación, no poder testear unitariamente ese código, y que SQL no es un lenguaje enfocado en programar si no mas bien en consultar.

[@fabianastrada3733]

Si realiza todas las ejecuciones de BD en el codigo se puede llenar la memoria y colapsar, por ello es importante para todas las ejecuciones a BD para que haya un mejor Perfomance y agilidad en las consultas por si hablamos de consultas hablamos de millones de millones de datos imagínate si lo metes al código ?

[@ManuelZapata]

Tocas un punto importante. Si tienes un volumen muy grande de datos y los traes a la memoria de la aplicación, la puedes desbordar. Allí juega un papel importante la paginación y otras técnicas. No necesariamente significa que tengas que usar procedimientos almacenados, pero si es algo a tener en cuenta.

[@RupertoCoronado]

Actualmente estoy migrando un proyecto de escritorio a web y justamente me estoy planteando hacer uso de procedimientos almacenados de SQL Server, ya que el proyecto de escritorio se seguirá usando a la par que el web, es decir, usarán la misma base de datos (antes de mudarse a la nube)

[@ManuelZapata]

Entiendo. Pero existirá un backend que ambos proyectos usarán, o interactuaran directamente contra la BD?

[@RupertoCoronado]

@@ManuelZapata ambos actuarán directamente en la base de datos

[@ManuelZapata]

En ese caso los procedimientos almacenados ayudan a dar un poco más de control sobre el acceso a los datos. Sin embargo, en un mundo perfecto, lo ideal es que existiera un backend contra el cual ambas aplicaciones interactuaran.

[@RupertoCoronado]

@@ManuelZapata sí tienes razón. Lo ideal sería tener una API y que ambos lo utilicen, pero mi proyecto de escritorio está hecho en MS Access trabaja con una BD en SQL Server, y lo estoy migrando o reprogramando a python con Django, así que, un dilema, gracias por tu respuesta.

[@oldemarcortes1337]

Muy buen vídeo estaba buscando información acerca de este tema

[@ManuelZapata]

Con todo gusto Oldemar!

[@PruebaDesarrollo-ft6vf]

Creo que Manuel Zapata habla desde su experiencia y es respetable, pero cada programador vive un mundo de problemas y contextos muy diferentes a los de Manuel, como se puede evidenciar en los comentarios y habrá casos donde la solución mas apropiada serán los S.P... por lo anterior NO comparto su postura de que los S.P. ya no son necesarios.😉

[@MrLeonardonam]

Que hay Manuel.Mi jefe esta super casado con Oracle.En su opinion los procedimientos almacenados son super veloces y por lo tanto se niega a usar ORMS o consultas hechas desde el lenguaje.Yo creo que es mas bien por la estructura de la BD.Afortunadamente no he tenido que usarlos pero el hecho de que haya que alguien los use a veces dificulta la integracion,actualizacion o migracion a otras plataformas.EN fin. Buen contenido en el canal.Saludos

[@ManuelZapata]

Es difícil. Normalmente, o amas los procedimientos almacenados o los "odias" con todas tus fuerzas. No hay punto medio. Saludos Leonardo!

[@mikehurtado4772]

Siempre, sí o sí

[@FiliusDeiPatris]

Pero hay operaciones que son super complejas q segun mi opinion si conviene desarrollarlas en SP o package porque es mas natural y "abordabe" hacerlas alli. La verdad que no me imagino llevar la logica pesada de un package directo a un API (node por ej) ahora si la cuestion es simplemente crear u CRUD claro q no habria problemas pero en ambientes empresariales es todo mucho mas complejo, las transacciones son mucho mas complejas creo q lo abordaste de una manera muy simplista.

[@ManuelZapata]

Gracias por tu aporte a la discusión, Luis F. Lo de que sea natural o no, en realidad tiene un factor importante y es el background de la persona. Seguramente un DBA tendrá una opinión distinta a alguien solo conoce el mundo de los objetos. Me quedó la duda: a qué te refieres con operaciones súper complejas?

[@FiliusDeiPatris]

@@ManuelZapata Mas que nada operaciones que requieran mucha lectura y escritura de tablas...

[@aphipex]

Interesante tu punto de vista, no estoy de acuerdo pero quiero darte el beneficio de la duda y analizar tu punto de vista desde mi necesidades, no puedo estar más de acuerdo con el autor, pero hay tema que no se ha tocado y me gustaría saber desde tu experiencia, como gestionas los test, osea para aplicaciones heredadas los test siempre sin un dolor de cabeza, pero si voy a crear un sistema nuevo los test me dan un punto de seguridad y calidad que la verdad no veo como automatizar desde la base de datos y que no implique un proceso de test más complejo y lento que la propia lógica de la aplicación

[@PCcristian]

Y por el tema de seguridad, para evitar Sql injection y mejorar el rendimiento... de debería seguir utilizando...

[@ManuelZapata]

Gracias por tu aporte Cristian!

[@JuanCarlosChoqueQuispe]

En mi experiencia me sirvio de mucho utilizar procedimientos almacenados para reducir la carga del lenguaje de programación es decir, el lenguaje de programación estaba realizando muchas tareas lo cual reducia el performance del app, con los procedimientos esto se redujo, adicionalmente, es importante tomar en cuenta las Vistas (Views) que tambien son creadas en la BD y reducen bastante el tiempo que toma entregar al usuario datos en grandes cantidad o complejos (varias relaciones y proceso de datos)

[@ManuelZapata]

Me imagino que esas tareas estaban relacionadas con acceso a datos. Las vistas son muy útiles también! Gracias por compartir tu experiencia, Juan Carlos.

[@wiedens-justociurlizza7766]

Ers peruano? yo sí del rico norte de Chiclayo, me es muy grato leer tu comentario, se nota que tienes mucha experiencia ligada el sector empresarial.

[@JuanCarlosChoqueQuispe]

@@wiedens-justociurlizza7766 Hola, soy de Bolivia, llevo trabajando 14 años en el sector, estoy tratando de re-inventarme, aprendiendo nuevas tecnologías y profundizando el idioma ingles, todo esto sumado a los años de experiencia que tengo me hacen pensar que puedo trabajar en una empresa extrangera donde pueda conseguir mejores salarios

[@wiedens-justociurlizza7766]

@@JuanCarlosChoqueQuispe Buenas noches hermano boliviano, que carrera estudio? Al indicar que se esta reinventando es.porque a que se dedicaba o como solia trabajar? Soy del norte del Peru, e-commerce Developer. Saludos y exitos!

[@JuanCarlosChoqueQuispe]

@@wiedens-justociurlizza7766 Soy de La Paz, soy Ingeniero de Sistemas, en realidad siempre trabaje en el área pero me trabaje muchos años en solamente PHP-MySQL-Javascript, pero veo que ahora se paga mejor por desarrrolladores Javascript y Python en sus distintos frameworks, por eso desde hace 3 meses estoy aprendiendo estos lenguajes y mejorando mi ingles entre otras cosas, actualmente trabajo de manera remota para una empresa argentina pero mi idea es lograr trabajar en una empresa de USA o de EUROPA. Me alegro que estes en el área de e-commerce se que en Perú esto esta mas avanzado que en Bolivia

[@JavierMedina26]

Entonces tengo una pregunta que aplica para Oracle o SQL Server, cómo le haces cuando tienes una consulta complicada y se te dregada el performance, ya reindexastes y actualixaste estadísticas??? Esto lo pregunto porque he visto esto con el Entity y el MVC???

[@ManuelZapata]

Ahí tienes varios caminos, Javier. 1. Optimizar la consulta desde EF. Muchos problemas de performance vienen de usar la configuración por defecto. 2. Hacer la consulta SQL desde la aplicación. 3. Hacer un procedimiento almacenado. Si mi proyecto ya tiene un ORM, iría agotando mis opciones en ese orden.

[@billyhuaroc6378]

¿Y para seguridad al momento de hacer una página web con MVC?

[@billyhuaroc6378]

Me enseñaron a usar procedimientos almacenados para consultas simples más que nada. Para aumentar la seguridad, programando MVC con CodeIniter.

[@pablomaidana7420]

Relacionando con el vídeo, cual seria la mejor forma de ejecutar consultas SQL complejas?

[@ManuelZapata]

Si la consulta es muy compleja y el ORM no te está dando buen rendimiento, puedes evaluar hacer la consulta con SQL. Saludos Pablo.

[@sergioricardogeronimo5489]

Excelente video. Felicitaciones

[@ManuelZapata]

Gracias Sergio!

[@cpaez2000]

Yo creo que esta mal el enfoque que le estas dando. El trabajo que haces en un procedimiento Almacenado nunca podra ser sustituido por un ORM. Lo que pasa es que en el desarrollo web la mayoria de elementos que tienes son entidades y en un ambiente empresarial No. Por eso es facil no requerir de procedimientos almacenados. Pero por ejemplo si quieres hacer una consulta que involucre mas de 10 tablas. Es mas sencillo, rapido y facil de mantener hacerla en un stored procedure, que mapear todo esos en una entidad y ademas seria un error porque esta consulta de la que te hablo no es una entidad. Seria complicarte la existencia.

[@edwardmuri5895]

realmente no soy mucho del uso SP para desarrollar la lógica de negocio de una aplicación, ademas de acoplarse fuertemente el motor de BD este no tiene la versatilidad ni la flexibilidad de un lenguaje orientado a objetos, bastante complejo mantener ese tipo de aplicaciones y si no se es extremadamente disciplinado el hacer cambios continuos es como alimentar un pequeño monstruo que en algún punto extallara. en ocaciones necesitamos por obligación lógica del lado de la BD como por ejemplo detectar cuando se ingrese registre,actualice,elimine un registro(los clásicos triggers). para efectuar alguna logica En este caso que crees que sea lo mejor? en la definición del trigger llamar a algún servicio desarrollado en un lenguaje o llamar un SP local en la BD o de plano meter la logica ahi? o hay alguna mejor variante?

[@ManuelZapata]

Entiendo porque hay escenarios donde eso se implementa con triggers en la BD, pero yo personalmente lo haría a nivel de aplicación, y me aseguro que la BD sea accedida solamente por esa aplicación.

[@plinioarrieta2223]

Es díficil dejar PL/SQL de Oracle, porque 1) Es muy sencillo de aprender y usar 2) fácilmente puedes hacer cambios sin tener que hacer grandes compilaciones de aplicaciones. 3) Es muy eficiente y es rápido programar en él. La facilidad de declarar un dato tipo %TYPE o %ROWTYPE no te lo da otro lenguaje. 4) Si usas buenas prácticas puedes separar el código de la lógica de negocio con el de persistencia y acceso a datos. De tal forma que si hay que migrar a otra BD no sea mayor esfuerzo (Y aunque no se migre, por soporte y escalabilidad es lo mejor.) 5) La mayoría de problemas que he visto en PL/SQL es con las malas prácticas: redundancia de código que hace lo mismo, código espagueti, procedures con demasiadas líneas de código, falta de modularidad y encapsulamiento (variables globales por todos lados) 5) He notado que en todos estos años con PL/SQL mucho código escrito en otros lenguajes (y frameworks) se ha quedado obsoleto y PL/SQL sigue ahí y funciona mucho mejor que antes. Mi Conclusión: si es una empresa muy grande no le veo problema a que use PL/SQL en cosas que sean únicamente del core del negocio. Pero que se usen buenas prácticas separando la lógica de negocio de la persistencia y acceso a datos.

Y que pasa si tengo que usar transact para hacer consultas muy específicas? O todo se puede resolver con un orm?

[@ManuelZapata]

Todo se puede resolver con un ORM. El tema está en que tengas bien configurado el ORM para que la consulta sea eficiente.

@@ManuelZapata Gracias!

[@leonardopalomino2649]

Pensar como Programador o como DBA que dilema. Yo prefio pensar como dba facilita las cosas a la hora de programar. El tema de orm lo veo como mas una moda pero ambas son eficientes. Para las cosas complejas como consultas o validaciones extensas y para aplicaciones enormes los sp son un buen apoyo. El tema de la migracion de base de datos podria manejarse tratando en lo maximo posible utilizar ANSI SQL, siempre me enseñaron que no importa el motor de BD que elija, trate de usar ANSI SQL facilita una posible migracion. De todas maneras hay consecuencias de elegir un metodo: Si eleges sp tendran un monstruo de codigo de logica de negocio en la BD, y si eliges orm tendras un monstruo de codigo de logica de negocio en la aplicacion.

[@ManuelZapata]

Cada enfoque trae sus pro y sus contra. Yo personalmente creo que los ORM no son moda. Ya llevan varios años, y también es posible crear consultas muy eficientes con estos. El ANSI SQL ayuda bastante, aunque es muy fácil terminar saliéndose del estándar. Saludos Leonardo!

[@omarrosas5524]

Hola. Esto es algo similar a ORM?... Lo comprendo así.

[@ManuelZapata]

No Omar. Esto es algo diferente. Es código que corre en la base de datos.

[@leviatanMX]

A mi en lo personal dejo los SP's para ejecutar procesos de actualizaciones masivas, calculos, para lo que le llamamos CRUD en ASP NET MVC con C# prefiero un microORM como NPOCO que es rapidisimo, y para escritorio desarrollo en PowerBuilder, en la que con el DataWindow, no tengo que andar escribiendo sentencias para hacer update, select, delete, insert.... ADEMAS de que al manejar todo en los SPs es casarte con esa B.D. , un dolor de cabeza una migracion a otra B.D.

[@ManuelZapata]

Gracias por tu opinión, Leonardo! No conocía NPOCO. Voy a leer un poco más sobre él.

[@sirfreedom]

GENERALIZAS MUCHO... y te cuento porque. al momento de decidir si queres hacer la logica de DATOS en la base de datos o en el codigo tenes que pensar en dos cosas.. 1 si vas a ir moviendo los datos de un lugar 2. a otro y si esos datos son pesados, desarrolle una aplicacion para gestion de salarios de empleados, no es muy dificil imaginarlo, una liquidacion conectada a itemLiquidacion, pero sucede que cuando vos ingresas un ITEM en la en cada liquidacion hay muchas cuestiones a nivel salarial que tenes que RENDERIZAR DE NUEVO, o sea tenes que recalcular quizas 6 meses para atras, y en la liquidacion que estas analizar como impacta eso a la liquidacion que tocas. entonces? no es por lo lindo.. es por lo CARO que te puede salir mandar 6 meses de liquidacion a tu aplicacion, manipular los datos, con otros datos que tambien deberias mandar... o bien hacerlo directamente en la base... no se cuanta experiencia tenes.. pero yo soy ingeniero en soft con 18 anios en la industria y he tocado aplicaciones bancarias, de supermercados y en esos rubros tambien se utiliza de esta manera.

[@ManuelZapata]

No sé que tan bien funciona tu ejemplo, la verdad. En ese caso particular que mencionas, quizá sea mejor guardar los valores en vez de estar recalculando. Sobre todo, porque la forma en que se hace el cálculo puede cambiar. Por otro lado, intentar justificar tu respuesta porque así lo hayas visto hacer en 18 años, no significa que sea la única forma. Yo llevo 17 años en esto, y también he pasado por muchas industrias.

[@sirfreedom]

@@ManuelZapata Los datos por momentos quedan fijos, pero tambien tienen volatilidad, sino no te hubiese hablado de una liquidacion ni de un item liquidacion, te hubiera dicho, todo se calcula para atras. decir que usar procedimientos almacenados esta mal, es decir que las futuras versiones de los motores de base de datos no van a traer procedimientos almacenados, ya que si fuera tan ineficiente los quitarian, o sea que la gente que estudia DATOS con un EXECUTION PLAN para ver el fluido de mucha informacion esta mal. no se.. es lo que decis vos.. por eso dije que generalizas. todo esta bien si usas un ORM. y hay gente que usa ORM y tambien programa para el culo. esta todo en una linea muy delgada de que es bueno y que no.. saludos.

[@claudiomanzoliz4378]

Pienso que cometes un error. Los sp no solamente se usan por esas cosas que dices. No hiciste mencion a la inyección sql y el rol que cumplen los sps. Ademas cuantas veces has migrado un sistema de una bd a otra? Eso no se hace en el 99% de tu vida laboral y hay motivos para eso. La verdad es que venka plr argumentos solidos que me permitiesen expandir mis horizontes, pero en lugar de. Eso he terminado decepcionado

[@eloyrangel]

A mi en lo particular me ahorra mucho código, ejemplo tengo una aplicación de comisiones de brokers que tiene calcular la comisiones dependiendo de muchos eventos, y los triggers hacen el trabajo cuando detectan el cambio, en lugar de estar ejecutando código ..y...donde se le pase al programador por que estamos fritos... Saludos!

[@andresbuitront2564]

Me parece que el uso de procedimientos almacenados puede ser mejor en ciertos escenarios por ejemplo, en .NET, con Entity Framework cuando se hace uso del ADO. Net este hace llamadas a la base por cada acción lo que disminuye el rendimiento, lo que se soluciona solo con SP. en mi humilde opinión

[@ManuelZapata]

El escenario que mencionas con EF depende mucho de como interactures con el contexto. Tu podrías, por ejemplo, acumular varios "insert" y mandar a ejecutarlos todos al mismo tiempo. Gracias por tu aporte, Andres!

[@claudiohuerta1305]

Y SmarDB o Thick db ?, a mi me parece correcto crear un api de acceso al sistema, es decir, se debiera poder manejar todo el sistema desde una interfaz de comandos, atravez del api de la aplicacion.

[@ManuelZapata]

Anotado en la lista de dilemas. Gracias por el aporte Claudio!

[@amcompe]

Para nada de acuerdo, buen debate

[@christianmagnus1003]

La logica en la base de datos esta mandado a recoger hace mucho rato, por algo todos los lenguajes tienen ORMS y estan las diferentes arquitecturas como las 3 capas, n capas etc, la tendencia es dejar a la bd como su nombre lo indica guardar datos, la logica del negocio en la bd te limita si quieres usar una bd mas robusta porque la app tiene crecimiento exponencial te jodes, y el cambio de lenguajes backend se da muy poco, y cuandi se da no es por una necesidad imperativa es mas bien por cuestiones de actualizarse.

[@itrosky]

No lo se... Tener código en la base de datos le da flexibilidad a la aplicación. Es decir, podrias cambiar ciertas cosas que haces con datos sin necesidad de sacar una nueva versión de la aplicación y por lo tanto una nueva publicación... Igual no todo se lo dejaría a la base de datos. Sin embargo, yo soy DBA entonces pienso en T-SQL por default!!! Jajajaja

[@ManuelZapata]

Jeje claro, y en tu experiencia como DBA es más fácil manejar código en la BD. Lo único que añadiría a tu comentario es que así sea código en la BD, hay que versionarlo y publicarlo. Puede que no sea complejo como sacar una versión del sistema entero, pero hay un trabajo similar.

[@victorpinedo5121]

Yo personalmente nunca he estado de acuerdo en situar logica de programación en los Gestores de bases de datos, de hecho hasta donde se, los patrones de diseño y arquitectura de software, no dan muchas luces en ese tipo de práctica, y sus orientacioes y recomendaciones, se centran en la logica de negocio que se plasma propiamente en la Aplicación.

[@victorpinedo5121]

Manuel recomiendame un Lavalier MIC para comprarlo y empezar a grabar unos videitos, ese microfono de solapa que tu tienes, se ve que funciona muy bien

[@ManuelZapata]

Sí, lastimosamente ni los patrones de diseño ni los de arquitectura hablan puntualmente de este tema. Aunque si hay que destacar que los patrones de diseño hablan puntualmente de programación orientada a objetos.

[@ManuelZapata]

Este es el que yo uso. Muy bueno! www.rode.com/microphones/lavalier

[@victorpinedo5121]

@@ManuelZapata Empiezo con mi canal en muy poco tiempo, encargue ya un microfono, espero hablar tambien de arquiectura!, pero primero debo aprender de ti jajajaj

[@ManuelZapata]

Me avisas cuando publiques tu primer video! En lo que pueda ayudar, con mucho gusto.

[@claudiohuerta1305]

SmartDB:

[@ManuelZapata]

🤔

[@andresnator]

De acuerdo, larga vida al ORM!

[@ManuelZapata]

Larga vida!