¿Usar procedimientos almacenados? | El debate con
Вставка
- Опубліковано 20 вер 2024
- En este live estaremos conversando con Héctor de León sobre nuestras opiniones encontradas acerca de los procedimientos almacenados (SP).
Ya nos conocen. Nuestas opiniones y conceptos siempre son respetuosas y sin fanatismos.
Mi opinión sobre los SP en un video anterior: • ¿Deberías usar PROCEDI...
Video de Héctor sobre SP: • 🧙 La magia de los Stor...
![Would We Be Better Off Without Religion? - Christopher Hitchens [2007] ✝️ | Intelligence Squared](/img/n.gif)
Excelente video, soy el gerente de un core bancario y la lógica de negocio está en procedimientos almacenados, soy de los que aman los procedimientos almacenados. Saludos
no me canso de ver este video, esto ayuda mucho a travez de sus experiencias, se aprendo mucho uno como novato.
Genial Salvador. Saludos! 🙌
es mi segunda vez en un mes xD
Lindo tema! Prefiero los store procedure son más flexibles en sistemas grandes. Saludos @hdeleon desde Argentina!
Voy a citar la frase de Manuel en mi tesis sobre arquitectura :)
"Una buena arquitectura te hace tomar las decisiones correctas"
-Manuel Zapata
16:57
Hola Erick! La frase no es mía. La adapté del libro de Refactoring de Martin Fowler.
@@ManuelZapata Oh bueno gracias por la fuente, entonces pondré una cita doble para no tener problemas :)
Me encantó el video, y comparto puntos de vistas con ambos. Pero bien, hoy en día hay herramientas y maneras para compartir datos centralizados, por ejemplo WebApis y puedes tener toda la lógica de negocios del lado del código que sería el enfoque que yo usaria. Con esto si por alguna razón se toma la decisión de cambiar la db solo tendría que utilizar el driver de la misma y no tendría que programar otra vez en la db. Usuaria SP en casos de procesos complejos de prosa miento de datos, por ejemplo un cierre.
En la empresa donde trabajo los procedimientos almacenados se usa mas que todo para seguridad e integridad de la información evitando que se ejecuten consultas que puedan dañar la integridad de la información, otros usos que se tiene es el de cálculos simples.
Estoy de acuerdo de que la base de datos solo debe almacenar los datos, pero los procedimientos almacenados son una gran ayuda si queremos que la integridad de la información se mantenga y la verdad si que han servido en ese aspecto.
Conocimiento que vale ORO literal. Gracias por compartir.
El vs más esperado! Ryu vs Ken
Hadouken!
Hola soy nueva en su canal, Pero llevo mucho tiempo desarrollando de lo antiguo visual basic 6, ahora estoy desarrollando en c# en 4 capas y me encanto y todo lo desarrollo con stores procedures muy interesante el punto de vista de los 2. Me encanto la manera de trabajar los stores procesures en la capa de los datos me parece super practico y veo que es apliable a cualquier base de datos. Gracias por este debate.
Tengo compañeros que dicen que los SP son muy antiguos y quieren trabajar en un nuevo proyecto con la programación de la lógica de negocio en c#.
Debo decir que me empezó a gustar los SP
El procesar los datos en los store procedures es mucho más potente que llevar a esa lógica al código de cualquier lenguaje, es mucho más rápido
Yo utilizo procedimientos almacenados en Oracle y he logrado grandes mejoras en rendimientos de aplicaciones. He quitado lógica de las clases y las he pasado a Package de Bd Oracle logrando bajar tiempos de 5 min a 40 segundos
Tremendo live. Felicitaciones. Y como dijeron, los sp son una herramienta y es nuestra responsabilidad saber cuando y cómo hacemos uso de ella. Saludos y felices fiestas para todos!!
Felices fiestas Cristian!
Creo que este tema salimos de dudas cuando lo ponemos en la Practica con ejemplo de muchos registros , por ejemplo unos 500000 mil o mas registros ahí veremos la diferencia .
La base de datos no solo es para guardar datos. El programar store procedure es apuntar al rendimiento para aprovechar la potencia del server. Además algún cambio de solicitud de info la puedes actualizar el procedimiento. Sin tocar el código de la aplicación..
En esta de la seguridad estoy con Hector. Nunca lo hacemos. Pero por algo hay stores procedures definidos por usuarios. Que lo hagas no significa para nada que vas a ir directo. Pero si que tenes una mas. Como dice el es un punch extra
Muchas gracias Manuel y muchas gracias Héctor estos debates / y ver mas allá de un punto en concreto. Sirven muchísimos Les agradezco nuevamente. Es genial cuando se juntan!!!!😀
Me gustó el debate y aprendí y recordé algunas cosas que deje de lado. Un saludo a los dos.
Saludos Angel
Yo tambien le voy a los procedimientos almacenados, porque me ha tocado desarrollar un sistemas integrado donde involucra muchos modulos y por ende cuando se trabaja un un proceso el query demasiado grande porque integraba casi todos los modulo, llamadas a muchas tablas, validaciones procesar la información era inmenso lo cual sin procedimientos almacenado no hay forma.
Héctor Totalmente de acuerdo contigo. Muchos Exitos!
Hola Manuel, soy programador de la vieja escuela, si tu revisas cuales son los objetivos de los creadores de los motores de bases de datos, no fueron creados solo con la visión de solo almacenar datos, esa visión se manejo hace mas de 20 a 25 años cuando el almacenamiento se hacia en archivos dat, txt, cobol, dbfs, etc. Conforme los fabricantes fueron actualizando sus productos, estos han implementado mas funcionalidades de validación, reportes y programación que muchas veces serán mas rápidos de procesar dentro del motor y sobre todo también agregan una capa de seguridad extra. saludos
dure mas de un dia viendo la conferencia, pero valio la pena
saludos feliz navidad
Personalmente uso mucho mucho procedimientos almacenados o mejor dicho funciones, uso postgresql, meto mucha programación dentro de base de datos y me facilita enormemente mi trabajo ya que si necesito trabajar con datos me parece lo mejor que sea la misma base que procese sus datos y a mi aplicación solo le devuelva la respuesta. Además si necesito cambiar algo de la lógica no tengo que recompilar la aplicación y versionar en todos los clientes. Bueno son puntos de vista.
Que buen debate!! Muchas gracias por compartir sus experiencias Ingenieros. Brindan motivación y visión a los que venimos por detrás. Un saludo maestros :-)
Eso de añadir ensamblados a SQL Server me ayudo una vez que se requeria hacer una interface por base de datos (requerimiento del cliente, nada de webapi ni nada que se le parezca) y se necesitaba hacer unos calculos que ya estaban desarrolados en la aplicación (mucho trabajo volverlos a hacer en sql y hasta volver a probarlo). Así solo me toco sacarlos a una dll y mapearlos a una función SQL, y ya solo utilizarla. Cada cosa tiene su uso, tampoco es que a palo no se haría algo.
"Solo sirve para guardar datos", con ese pensamiento los desarrolladores crean a diestra y siniestra tablas y entidades q se convierten en verdaderos desastres para los DBA y las aplicaciones
Lo más importante es identificar cuando se deben usar y cuando no. Son herramientas y en algún momento te van a resolver un problema. Gracias por el aporte.
Así es Diego. Saludos!
Me encantan sus lives, apenas estoy viendolos poco a poco, pero es muy bueno, importante e interesante que gracias a su experiencia pueden darnos tanta informacion del mundo real. Saludos
Excelente debate. Solidos y consistente argumentos de Hector. Saludos cracks.
Gracias por compartir sus experiencias y conocimientos!!!
Impecable como siempre...gracias Manuel y Hector
Gracias a ti por siempre acompañar!
Excelente ambos, muy buenos temas. soy un pro "store proc" ojo solo he trabajado con estos y si me encantaría ver otras herramientas como las que menciona Manuel
Muy interesante este debate, siempre lo estuve buscando justo porque habían estos dos puntos de vista, pero me entraron dos dudas.
1 sobre la optimización comentaba Héctor que los Sps son más óptimos porque se ejecuta en local pero en el caso de hacer cursores?
Hasta donde sé por lo menos en SQL Server son el demonio, esto Héctor es cierto o es como una creencia? Lo digo porque si analizamos una sub query que tenga join con tablas derivadas y alguno tenga incluso unión, hasta en los casos bien indexados puede tardar por la volumetría de las tablas, índices etc, pero no sale mejor en algunos casos hacer un cursor y que haga la operativa o varios cursores simular lo que se quería en la query e insertarlo en la tabla? Lo digo porque me ha pasado de queries pergaminicas por el diseño de las tablas que tiene mejor rendimiento los cursores que esas queries, sobretodo porque en cada cursor estarías sacando una de las tablas o dos con algunos filtros y no toda, ya que resolver una y guardarla en el cursor no es lo mismo a toda la query entera y luego cada variable de cada cursor hace el "join" con las condiciones que se quieren hacer, vamos como con cualquier lenguaje de programación, en muchos casos ha sido más rápido.
No sé si conoces los script de ola hallengren pero son muy usados en SQL Server para los planes de mantenimiento y lo que siempre me hacía gracia es que los odiaban pero justo recomendaban los script de ola para los planes de mantenimiento jajaja siempre me pareció un poco contradictorio pero por saber si depende para ser un demonio los cursores por lo menos en SQL Server.
2 sobre las herramientas que dice Héctor de ETL no entiendo la parte donde dice que lo malo es que cuestan dinero, lo digo porque si es por SSIS es correcto pero con Pentaho y Talend no sería el caso ya que son gratuitas, o te referías a otro coste? En principio estas dos que te menciono son tan gratis como los sps jajaja.
Bueno no espero respuesta porque conocí el vídeo tarde ya pero bueno ahí queda.
Saludos desde España!
Concuerdo totalmente con el efecto devops en la forma de concebir y trabajar d ellos equipos
Que buen debatazo. Comparto la opinión de Manuel en la ronda 1
Me fascina BLAZOR... es lo máximo. NET8 biene con todo. Ups!
Hector es un crack y manuel es otro crack, mis respetos para los 2, manuel sos de cali? yo igual en la buena
Hoy en 2021 me gustaria haber formado parte de esta platica y desde mi punto de vista hablar de performance tunning herramientas como querys store y hablar de la carencia de developers y la curva de aprendizaje en SQL al ser un lenguage con tan "pocos cambios" es muy corta .
Buen vs, gracias por el debate, experiencias y lecciones aprendidas
Yo pienso que para todo aquello que no lleve tanta Complejidad, Usar un ORM es mejor por los beneficios que comenta Manuel Zapata, Pero cuando las cosas ya se complican y se tiene que manipular mucha información los Procedures son la Solución sin Dudarlo Bien allí hdleon.
2 horas de vídeo bien aprovechado. Gracias por sus puntos de Vista.
Los procedimientos almacenados son lo mejor. Los lenguajes de programacion y paradignas estas cambiando continuamente y eso hace dificil al programador ya que tiene que estas aprendiendo cosas nuevas todo el tiempo. El lenguaje sql server se sigue manteniendo hace años
como manejas el versionamiento o las pruebas unitarias o CI/DI ? como manejas SOLID ?? Ese modelo es de los 90s, hay que avanzar
@@hba6018 Regla para ser buen programador "Lo nuevo no siempre es lo mejor". C++ es utilizado en Unreal, averigua cuantos años tiene.
Hola @Manuel Zapata excelente debate, gracias por toda la información compartida. Qué opinan sobre los procesos batch , lo mejor es que se generen y ejecuten a nivel de la Base de Datos o desde aplicativo? En mi trabajo en la base tenemos cientos de crones, hace poco llego un nuevo arquitecto y decidieron que los crones se generen en Java, que me pueden decir sobre esto? Gracias a todos
Excelente vídeo felicidades!! y si estoy de acuerdo en el uso de sp por experiencia en un empresa donde igual todo el core del negocio estaba en sp que soportaban miles de llamadas de varios portales, públicos y privados y en donde la capa de aplicaciones en cs y vb solo servían de pasarela de datos...saludos..
muy buen tema!
vuelvo a este podcast para preguntar por alguna herramienta para versionar bases de datos, aiudaa
Flyway es una excelente opción: flywaydb.org/
hace tiempo un ingeniero me hablaba de una problemática por rendimiento, y que además necesitarían un server con una ingente cantidad de RAM. y me dijo, chino, eso con SP se puede solucionar. y yo quedé... ahh?? que es eso? JAJAJA. Me gusta la posición de Héctor, es como cuando tienes la botella de licor especial que sólo abres en ciertos momentos.
Yo aqui 2024 procedimientos almacenados es mi primera solucción
Muy buen contenido y las razones de cada uno son validas.
Excelente debate, saludos
Soy fan de hdeleon y he manejado sps pero prefiero los orms, saludos
No pude estar en el vivo. Yo voy por los Sp. Un cambio de consulta implicaría una nueva compilación de la aplicación, no?
Por otro lado también trabajé en empresa donde solo recibía los nombres de los Sp y solo los usaba. ya que era otro sector era quien se encargaba de la base de datos.
Tambien creo que está el tema de seguridad.
Abrazo
1. Lógica de negocio. El tiempo, todas las entidades públicas no van a reimplementar sus sistemas porque tú prefieres una capa de aplicación extra...
Otro punto seria la problemática entre programador y dba, que lo que hemos trabajado en ambientes donde existen dba prácticamente notrotos solo podemos conectarnos a la db. Por experiencias.
Me encanta trabajar con SPs, así sea con una API, por seguridad desagregación y rapidez
Charla muy interesante 👍
Muy buen video, de gran nivel, gracias!
con gusto Hugo!
Por favor siguiente video: Domain Driven Design Vs Modelo Aenimicos....
que buen contenido.. gracias por compartir.
Con todo gusto!
Antes de ver el video. Poner código SQL en la aplicación es muy similar a tener el código dentro de un SP pero con más desventajas!!. Espero encontrar algo bueno en este video!!
Que buen video
Aprender procedimientos almacenados es lo que anhelo he intento, veremos si Manuel Zapata Cambia mi pensar es en este video.
Team SP - es una herramienta. solo hay que saber cuándo utilizarla.
No estoy de acuerdo con eso de la Base de datos es solo un repositorio, los extremos son malos, si se aprovecha estratégicamente se puede simplificar la lógica, a muchos les encanta programarlo todo, extendiendo innecesariamente el tiempo de desarrollo, si es una empresa muy grande con recursos ilimitados... adelante... pero tampoco duraras mucho :)
buen tema de debate, Hector te invito un par de chelas en las Sirenitas, ahi nos vemos 🤣
Tienes un video de resumen, son dos horitas :c
Excelente video!!!
Voy a poner un comentario. Pl/Sql ha sido muy longevo. Con el tiempo, Java, C#, JavaScript, pueden cambiar y van a cambiar. Creo que para una empresa grande, es mas ventajoso. Con el paso del tiempo el cambio de los sistemas pueden cambiar y dejar toda la lógica del negocio en un lenguaje, ese lenguaje puede morir. Mucha gente tuvo una lógica de negocio en vb6 tuvo un gran problema para migrar. Estoy de acuerdo con De León. Tener la lógica el negocio en la BD puede ser mas seguro
Equivocado el de Rojo (Es depende)
Que pasa cuando hay empresas que tienen sus ambientes separados, frontend, backend y dba. Y estas personas ni siquiera se conocen, solo se rigen por la arquitectura. Y todo funciona bien y también se escala fácilmente con micro servicios. Yo solo he visto los query para los CRUD. Tampoco he escuchado que volver ha compilación la aplicación sea un problema, al estar todo automatizado, en un minuto se tiene todo listo, por supuesto cubriendo todas las líneas de código con test. No se como harán los dba pero en cuanto a mí en el backend solo me dediqué a la lógica, esa lógica luego se escala a varios países de manera rápida. No estoy seguro como trabajan los dba pero no sé si los procedimientos sean escalable de esa manera, más cuando las bases son diferentes según el país siendo la misma aplicación.
Hace 20 años que uso procedimientos almacenados en sql server, no hay con que darle en performance, cambio el procederé y no toco el cliente ni la API, no viajan datos por la red, si me queda negocio en ellos y es complicado el versionado y no son portables entre motores
Si no se usan los PA y se tiene que cambiar algo en algún query se tendría que recompilarla la aplicación 😕
En las soluciones complejas no hay "la aplicación". Hay muchas aplicaciones.
Las subconsultas son tremendas, los procedimientos almacenados dominados en objetos personales de dominarlos es lo maximo
Gracias por comentar!
Yo Vi procedimiento almacenados en la universidad este año
Hola muchachos buenas noches !!!
Excelente arguments de ambos parks. A la final, todo depends de la necesidad
He comprobado los SP aumentan el performance cuando el modelo relacional en base de datos supera 3 niveles de jerarquía Ej. TablaPadre, tablaHijo, tablaNieto. Alli es donde el modelo orientado a objetos se queda a leguas
Pero no todo es rendimiento, no siempre tienes porqué meterlo en sp, El round de mantenimiento y escalabilidad sin duda es para Manuel
Creo que hector gano en todas
Me perdí el live :(, en mi experiencia los mayores problemas que he tenido para migrar aplicaciones son cuando la BD tiene la lógica de negocio y si le empezamos a dejar mas tereas a la BD se pone todavía mas peligroso p.e. el envió de mails.
Sobre el rendimiento, muchas veces se cree que los SP's van a mejorar el mal diseño de la BD y querys pero eso es solamente parchar un problema. Sin embargo, hay escenarios particulares en los que el rendimiento si es mejor p.e. table valued parameters y common table expression., en un CRUD simple la ventaja es insignificante.
Dejo mis pruebas por si a alguien le sirve:
ua-cam.com/video/0oVEURcAuQE/v-deo.html
Saludos!
Siempre
Me parece que Manuel nunca logró decir un buen argumento; me da la impresión que es un programador con una muy mala experiencia con los SP y seguramente el contexto en el que se ha movido le ha permitido evitarlos, no obstante los SP son una herramienta que tiene sus ventajas y su uso siempre está ligado a la experiencia del programador.
Me parece que la discusión no debe ser en tono de usarlos o no usarlos debe ser en cuándo es bueno usarlos y contexto de uso. Como bien dice Manuel, hay tecnologías que pueden evitarlos y que son óptimas sin llegar a ser la más óptima, pero con eso basta; pero concuerdo mucho con Héctor, un programador no sólo hace una cosa y no sólo se enfrenta a un contexto.
Me decanto más por la visión de Héctor, son una herramienta muy útil pero queda en el expertis del desarrollador saber cuándo y cómo.
El code-first con ORM produce modelos de datos anémicos.
Cuando dicen versionar la base de datos se refiere al esquema y no a los datos? Hablando de algo como MySql. Saludos.
Así es Alex. El esquema y también el código que tengas ahí (funciones, procedimientos, triggers, etc)
@@ManuelZapata excelente, que bueno que lo aclaras por que uno pensaría en que precisamente funciones, triggers no aplica pero la verdad es que si. Genial el video.
Antes de ver el video, voy a dejar mis opiniones de porque no usar SP:
- Lógica de negocio acoplada a la base de datos
- Para escalar, tenes que escalar a nivel de base de datos
- Inexistencia de unit tests o muy dificultosos para hacerlos
- Y relacionado con los unit tests, no se pueden integrar a un pipeline de integración continua
10:15 Se dice que al migrar de web forms a mvc fue fácil porque ya estaban los SP hechos y no tuvieron que modificar nada. Esto, no es una ventaja de los SP. En .NET tendrías que tener la lógica en un DLL aparte y solo modificar la capa de web form/mvc y ya y consumir la lógica desde la DLL donde tengas tu lógica.
Me ahorraste el comentario Roy.. Es correcto, no entiendo por que tienen que hacer un video de 2horas cuando todo se resumen en una frase "NO PONGAS LOGICA EN TU BD" no lo hagas, está mal por donde lo mires.. Ya otra cosa es que tomes un proyecto legado de hace 20 años llenos de SP's es otro cuento, pero si comienzas un proyecto NO LO HAGAS, y si depronto tienes la posibilidad de salirte de los SP no lo dudes
La argumentacion del Cabezon sobre cargar dlls en store procedures es fuerte ... Si no encontras pibes nuevos que entiendan un store procedure, imaginate un pibe nuevo que ademas entienda un store procedure que ademas carga una dll! Yo estoy con Manuel. Y si ademas estas desarrollando y algun cache tiene que recargar a menudo la dll ... Un tiro en las bolas @hdeleonnet!
Completamente de acuerdo con Manuel. Stored procedures = acoplamiento + inmantenibilidad.
Team functions and stored procedures
👌
Una cosa que no charlaron sobre la velocidad de los stores procedures es que a medida que aumenta la logica de negocio en los SPs,, y sobre todo si se usan bibliotecas externas van a empezar a agregar a los stores cosas mucho mas lentas como subir a ftp, acceder a apis externas o mandar mails ... Y toda esa carga va a ir a parar a cargar la base de datos.
Las SP abren la puerta a la automatización, punto para las SP
No uséis cursores!!!
team procedimiento almacenado :vvvvvvvv
Yo personalmente soy más del punto de vista de Manuel, por temas de escalabilidad y mantenimiento, aunque donde trabajo actualmente, promueven el uso de los SP por temas de rendimiento, y mi duda existencial es la siguiente, pues no he tenido tiempo de hacer los testeos...:
El ciclo que se hace si es desde código sería el siguiente:
1- Obtengo los datos, ya sea con una query directa o con un Micro ORM.
2- Los trato y proceso.
3- Los guardo, con query o Micro ORM.
En cambio en un SP, los 3 pasos anteriores se hacen desde el mismo punto.
¿Es más rápido el SP por no tener que hacer los traspasos masivos de información? Porque diría que prácticamente cualquier lenguaje de programación es más rápido en la manipulación de datos que SQL. No sé ustedes qué piensan, ojalá me lo puedan responder, eso me ayudaría mucho.
Ami me pasó algo curioso, en un trabajo había que hacer un reporte con cientos de miles de registros de muchas tablas en MySQL, la consulta tardaba unos 4 min en hacerse porque pasaba por muchas validaciones, se pasó a sql server y se bajó a 2 minutos, en sp con sql server bajo a 1:30, lo cual era muy bueno. Pero yo por curiosidad hice las consultas manualmente en MySQL y procese todo desde angular, todo parecía brujería todo el proceso solo tardaba segundos, no entiendo de dónde viene el alto rendimiento de angular, pero desde entonces he dejado de usar sp
Min 1:51:51 Con todo esto que esta diciendo Manuel Zapata lo dijo todo. Porque no recomienda usar SP? porque el como mucha gente lo ven dificil de aprender, esta en una zona de confort con los ORM, es decir que su patron de diseño es el "ORM Golden Hammer". Hijole...es una lastima que esta manera de pensar mediocre invada las redes sociales y todavia recomienda no usarlo...por Dios. En cambio Hector tiene un panorama mas claro porque tiene mucha, pero mucha mas experiencia. Esto ni siquiera deberia de estar en debate. Yo uso ambas tecnologias porque cada una resuelve situaciones distintas.
Programacion con paradigma relacional que es eso?
Antes era un heter de los procedimientos almacenados, pero con todos estos argumentos que dio a favor, y cuando trabaje con ellos, los quiero un poco mas, pero parece que yo no les gusto, me parecen bien dificiles de entener y siempre me fallan xD
Felicitaciones por generar estos espacios pero siento que en una parte informaron y en otra desinformaron.
Hola Michael. En qué consideras que hubo desinformación? Podrías profundizar un poco? Gracias.