¿Cómo RESOLVER el Problema del N+1? Tarde o temprano TE VA A TOCAR 💀

Рет қаралды 30,252

Күн бұрын

Пікірлер: 95

@hdeleonnet 11 ай бұрын

Mis Cursos de Programación: hdeleon.net/cursos-premium/ Mi Nuevo Libro: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/

@oreoslawiet355 11 ай бұрын

Cómo puedo conseguir tu libro con un autógrafo?

@rafageist 11 ай бұрын

Y hay mas variantes.... pero depende del problema a resolver

@benjaminsepulveda1664 11 ай бұрын

Excelente video, solo agregar que si quieres ver el rendimiento de las consultar utilizar explain para ver el plan de ejecucion y ver los costes de performance de la query, para los casos donde se necesite performance

@keiryliza 11 ай бұрын

HACK!!! Temazo, desde ya esperamos el truco de la carga perezosa. ¡Gracias por el contenido, saludos! ❤

@_LeoDev 11 ай бұрын

Buena esa la del JSON, no muy común. Ver C# me hizo recordar mis inicios 🥲 Buen contenido 💪

@sentadoensilla 11 ай бұрын

Desde que descubri las funciones json en postgres, uso la tercera forma

@sarracenogamer7375 11 ай бұрын

Muy bueno el video, me acaba de pasar el problema y tus ejemplos me han venido de maravilla para elegir la solución acertada, esperando el video con el "lazy" :)

@ZohKrahM 7 ай бұрын

La segunda, en lugar de traer todas las cervezas, se podría traerlas filtradas de la base y ya.

@ivanmr6742 11 ай бұрын

Ese metodo con Json es muy bueno 🤘

@galaxynote795 2 ай бұрын

Brutal!! ☠️

@dennmendezdel 5 ай бұрын

Excelente video.

@elgertz447 11 ай бұрын

Con todo viejo ❤

@saulantoniomorquechocela5381 11 ай бұрын

Los primeros dos los utiliza a pero no sabía que eran algo ya específico, pero el último me voló la cabeza ahora a investigar que tanto le pega al performance

@pablonardi4416 11 ай бұрын

Muy buen video. Me encantó. Me sirvió mucho cuando mostraste como hacerlo desde la DB

@Lidamster 11 ай бұрын

Muy buen aporte esa forma de conseguir el JSON, no la conocía! Sin embargo, creo que no es la mejor opcion para la salud de la BD. Para ella es preferible devolver la info desnormalizada y en formato tabla que andar utilizando recursos en generar un JSON

@jonathansantos6000 11 ай бұрын

Excelentes soluciones, eres un crack

@DestroyWolves 11 ай бұрын

Qué opinas del manejo de datos en tablas verticales, donde cada registro represente un valor de un encabezado relacionado y no una columna como se acostumbra ¿En qué casos es optimo usarlo?

@christopher8229 11 ай бұрын

Gran aporte. Muchas gracias

@GermanMacias 11 ай бұрын

en java se hace la consulta jpa con join fetch, y la propiedad del objeto se declara como Lazy :P

@matsoft.oficial 11 ай бұрын

Gracias Cabezón me has ayudado a resolver un problema de n + 1

@joseangelsanchez5357 11 ай бұрын

Utilizando el .Include() vendría siendo lo mismo que el JOIN, no? Saludos, gracias por tu contenido.

@danielhernandezmanzano6116 9 ай бұрын

Genial!!, buen video Gracias :)

@emersson7x 11 ай бұрын

Interesante... 🤨👌👌👌🧐 Buen video, gracias por el aporte. 👍

@Magistrado1914 10 ай бұрын

Excelente vídeo y contenido. Visto en 04/03/2024

@girondavidfour 11 ай бұрын

Gracias por compartir este conocimiento. PDT: Quiero ver la forma perezosa jajaja. Me identifica :/

@juanscasado 11 ай бұрын

Gracias!

@LeonardoVargasL 11 ай бұрын

Muchas gracias! Lo entendí. Tuve está pregunta en una entrevista y no supe cómo responder😢

@lucaseto 6 ай бұрын

Include???

@rodolfotovartorres 11 ай бұрын

que no ibas a actuar como snape para el reboot de harry poter no lo digo yo, lo dijo brais moure , como siempre gracias por compartir tu conocimiento saludos hermoso

@hdeleonnet 11 ай бұрын

😂

@midscarlosespinoza 11 ай бұрын

Me gusto la parte de las tripes comillas, esa no me la sabia 😀

@gabyyhshss 9 ай бұрын

Hay alguna relaciôn con Lazy Loading y N+1?

@jesussotillo107 10 ай бұрын

Hector y meter un .select despues del where para traer la data que necesitas que ventejas o desventajas nos da?

@EnanoForro 11 ай бұрын

No sabia que se podia generar el Json desde SQL. A partir de que version esta esa funcionalidad? O siempre se pudo hacer y recien me entero? Buen video

@danielsanchez928 11 ай бұрын

Es algo nuevo, pero no se desde que versión. En versiones viejas de SQL Server, se podía devolver un fichero csv

@miguelprado9388 11 ай бұрын

aquí iniciamos un nuevo semestre

@murphishouse 11 ай бұрын

Hola Héctor te harías un video de programar y configurara para alta disponibilidad, para muchos usuarios?

@nazgulresebo 11 ай бұрын

Lo malo del where/contains es que lo va traducir a un IN en SQL y tiene un límite. Está bien chida la tercera opción jaja

@fabioalfonso2144 11 ай бұрын

Hola amigo, a que limite te refieres?, no encontre documentacion sobre el tema, podrias aclararme la duda?

@nazgulresebo 11 ай бұрын

@@fabioalfonso2144 Linq traduce esas expresiones a una consulta SQL. Sería una consulta de este estilo SELECT * FROM TABLE WHERE CAMPO IN ('VALO1', ..., 'VALORN'), pero lo que hay dentro del IN tiene un límite. Esto dice la documentación: Explicitly including an extremely large number of values (many thousands of values separated by commas) within the parentheses, in an IN clause can consume resources and return errors 8623 or 8632. To work around this problem, store the items in the IN list in a table, and use a SELECT subquery within an IN clause.

@nazgulresebo 11 ай бұрын

@@fabioalfonso2144 Lo que pasa es que linq traduce ese tipo de expresiones a una consulta de este estilo: SELECT * FROM TABLE WHERE CAMPO IN ('V1', ... , 'VN'). Lo que va dentro del IN tiene un límite. Esto dice la documentación: Explicitly including an extremely large number of values (many thousands of values separated by commas) within the parentheses, in an IN clause can consume resources and return errors 8623 or 8632. To work around this problem, store the items in the IN list in a table, and use a SELECT subquery within an IN claus

@erickdiaz3553 11 ай бұрын

Que opinas de usar un SP para obtener los datos y un DTO para resolver este problema ?

@erimaykenta 11 ай бұрын

Bastante elegante!!

@chybeat 11 ай бұрын

No me gusta la onda "hardmetalera: (y no fué por lo que vine aqui), así que excelente video... un suscriptor más :).. PD: Los unicornios de Colores y las nubes de algodon son lo mio! 🦄🌈

@odingaming5698 11 ай бұрын

El metodo del json no lo conocia, me lo apunto para futuro

@AlexanderSosa-t3w 2 ай бұрын

Puto maestro en Conceptos...optimizado

@MesacMovies 11 ай бұрын

Lo de JSON es una locura!

@geovannimv3854 11 ай бұрын

Siempre que hay un video nuevo trato de no perdermelo, excelente video. Gracias!!! Tienes algún curso de Azure Files, Blobs? Saludos!

@sienfil 11 ай бұрын

Con la segunda opción le agregas un rompimiento de control y listo, los programadores de los 80's y 90's lo usaban, inician e imprimen la maca, mientras sea igual imprimen las cervezas y solo la vuelven a imprimir la marca cuando cambie. Es como agrupar se usa mucho para informes que tienen que totalizar por algún grupo. como dice Héctor cuando tienes montones de datos y en un servidor remoto viene el problema, otra que yo uso es UNION ALL y uso campos combinados con un identificador que me dirá que es cada uno, por ejemplo un Id, campo clase y un campo ordenador, el Id identifica si es una marca o cerveza, el campo clase irían las marcas y las cervezas y el ordenador, lo va a poner todo en su lugar, para informes complejos como los contables o financieros funcionan ya que la carga queda a cargo del servidor SQL y no de la aplicación, hacer esos cálculos por c# resultaran lentos.

@cguimaraenz 11 ай бұрын

Buenas noches! Creo que te refieres al INNER JOIN, cierto? El problema no está en la presentación de los datos, que como bien dices, se puede formatear a gusto, sino en la carga de información viajando desde el servidor de la DB, ahí es donde se hace costosa la repetición de información. Saludos!

@sienfil 11 ай бұрын

Hola@@cguimaraenz, como alguna vez lo dijo Ector, hay que ver a sql como un lenguaje de programación y no como un lenguaje de consulta, lo cual nos permite jugar con los datos, en el ejemplo lo que planteo es que en una misma columna se almacena las marcas y las cervezas y una columna identificador la cual nos dice que es, marca o cerveza, se imprime uno debajo del otro sin repetir, lo cual nos da mayor velocidad si los datos fuesen mas extensos. para eso sirve UNION o UNION ALL, combina datos.

@juliocrey1 11 ай бұрын

@@sienfil Es lo que pensé. Escribí la consulta para pegarla aquí pero no me lo permite KZbin. Hablas de un primer select con inner join entre marcas y cervezas, luego un union con marcas. Queda todo en una sola columna pero al primer select se le puede hardcodear " - " para diferenciar las cervezas de las marcas. Y sí, se traen solamente 13 registros en una sola columna, solo lo que se va a mostrar en pantalla. Maquina cliente y red no afectadas, servidor haciendo una subquery pero supongo que el Json también lo hace.

@academic3044 11 ай бұрын

Estimado Hector, mi hermano excelente video. Tengo una pregunta que requiero que me ayudes, re4sulta que tengo una DB que cada año crece en 10 millones de registros en en una cierta tabla de la DB, ya que cada 10 minutos almacena información que se tiene que si o si guardar como histórico. Que solución me aconsejas para evitar que después de varios años las consultas comiencen a ser mas lentas por la abrumadora cantidad de datos? Seria bueno dividirlo varias DB o migrar a un servidor RDS de AWS por ejemplo con mayor capacidad?. Por favor me ayudas con tu experiencia en esto, necesito tomar una decisión sabia.

@TheLinkrs 11 ай бұрын

Para ese caso de uso lo mejor es Sharding

@juan.olivas 11 ай бұрын

La del JSON me falta por implementar, ese escenario lo resolvía con el método anterior al json

@lhmendoza6083 11 ай бұрын

2016 me parece.

@juan.olivas 11 ай бұрын

??@@lhmendoza6083

@andresleonardo9686 11 ай бұрын

Que hay del SelectAll?

@togacentral 4 ай бұрын

Chingón....

@acmesoft 11 ай бұрын

Yendo un poco más allá del contenido del video que me pareció excelente: Hago unas preguntas desde mi ignorancia. Usar Queryable no presta ninguna ventaja con el tema del uso de memoria tanto en el servidor SQL y el de backend para este caso? (creería que sí pero como no conozco bien en profundidad no quisiera arriesgar, o sólo dilata el tiempo en cuando se ejecuta la consulta en el servidor de base de datos) (¿este caso que nombré es al que le llamas carga perezosa?)

@hdeleonnet 11 ай бұрын

ToList() regresa List, no IQueryable

@nazgulresebo 11 ай бұрын

Se ve que conoces mucho de cervezas deberías de abrir un canal al respecto.

@jose6433 11 ай бұрын

men, pregunta en serio, con esto puedo ser jefe de proyectos ya?

@tortorhl 11 ай бұрын

Te pases de v*rg yo me llamo Héctor León... pense que era el unico. Edito: ¡Espero el vídeo de carga perezosa, nuevo sub!

@cesarolivera117 11 ай бұрын

Ya llego a 2k likes, haz el video de "Carga perezosa"

@dev_crios 11 ай бұрын

Ya que últimamente estas tomando vino , por respeto a la cerveza, deberías dejar de usarla en los ejemplos.

@ItaloGuevara-f1b 11 ай бұрын

Ya quiero ver la forma perezosa

@Dan98475 11 ай бұрын

Nuevo video pendiente..., 2.1k...

@luxdev4719 11 ай бұрын

Crear un arreglo de objetos hijos para cada elemento padre, es lo que mas utilizo en mi día a día. Este video es un buen material para aquellos que aun no saben como lidiar con este asunto.

@RickychavezDeveloper 11 ай бұрын

usted hizo pacto con el chamuco para ser tan pro

@andreij2589 11 ай бұрын

Si HdeLeon es tan bueno porque no hay HdeLeon2?

@marliote 11 ай бұрын

Be unique

@omarsanchezcuevas8309 11 ай бұрын

Hoy me levanté recordándo que hace unos meses estaba sufriendo por esto sin saber que era el famoso n+1 Tu video me ha sido de mucha ayuda para entder el problema ✌️

@JJsCR98 11 ай бұрын

Yo para todo eso solo hago SP de lo que ocupo y desde BackEnd solo hago un llamado. Claro siempre full JSON, la mejor opcion es la ultima.

@argeliodelarosarodriguez6730 11 ай бұрын

Eso tiene un costo tremendo en BD, primero tiene que hacer subqueries, luego transformar el resultado en json y de ahí transmitir el json a la aplicación, lo cual implica también costo a nivel de red. Si no se va a usar el resultado como un json en la aplicación, entonces, al llegar el resultado habría que deserializar la data, lo cual implicaría otro costo adicional.

@JJsCR98 11 ай бұрын

@@argeliodelarosarodriguez6730 Si puede ser un problema, yo lo que hago son consultas super optimizadas, con campos necesarios solamente, claro que me ayudo con los indices, lo que hago es monitoriar siempre los query ya si veo mal echo no lo hago por SP, si los resultados de las consultas son consistentes lo meto un tabla de cache para evitar consultas innecesarias a la BD, sobre el nivel de red comprimo los datos del JSON antes de enviarlos, es dependiendo de lo que se requiera tiene sus pros y contras se puede usar Protocol Buffers o MessagePack, que son más ligeros en términos de tamaño y más rápidos de serializar/deserializar. Esto es importante que no influya negativamente el performance del sistema. Por lo que es importante realizar pruebas y mediciones para evaluar el impacto de cada cambio en el rendimiento y la eficiencia.