Directo debatiendo sobre los comentarios de este vídeo: th-cam.com/video/ezeU-MaKH1s/w-d-xo.html Curso Modelado del dominio: Proyecciones bit.ly/curso-proyecciones
Product Owner: Cuánto te demoras en mostrar la tabla en la página web Desarrollador: Como 3 meses Product Onwer: Qué? Por qué tanto Desarrollador: Es que mira ....
@@Bleibruk Por eso está solución, no es para todo el mundo ni aplica al 95% de los casos de usos. Sólo los que tengan un problema de rendimiento preocupante en algunos de sus endpoints, podrá llegar aplicar algo como esto. De todas formas, evitar el uso de joins es una práctica bastante extendida cuando se hace DDD. Pero lo dicho, esto no se da ni se dará en la gran mayoría de empresas, solo una minoría puede llegar aplicar algo como esto.
opino lo mismo, para ganar cuántos ms? es más práctico hacer un store procedure para cada caso en concreto que agregar tanta complejidad para q vaya 50ms más rápido
Gracias, gracias por el contenido, muy bueno y aplicable. Únicamente los títulos de los videos no los veo para nada acorde al contenido. Por ejemplo, acá están entregando una master class (y en otros videos) muy profesional, contenido de alto nivel, muchos jr/mid no entenderían estos conceptos, ni las preocupaciones a los problemas que resuelvan acá. Considero el título no hace justicia al contenido, yo por ejemplo entré negativo (como muchos otros que comentan risiblemente) esperando escuchar alguna burrada, pero sorpresa: No, es contenido excelente! Obviamente, el canal es de ustedes y les ponen los títulos que quieren a los videos, pero si algún día busco: Como mejorar rendimiento de consultas en DB relacionales, seguro este video nunca saldrá. Por lo que me imagino este conocimiento no se indexaría, más bien serviría para la primera semana y luego olvidado. Personalmente, dejaría títulos extraños para reels/tiktoks/etc. Mi resumen: Conocimiento profundo escondido en títulos dudosos. Mejor título: Cómo y cuándo evito usar JOINs
@@norbertocontreras4725 Yo creo que es un feedback constructivo, reconoce el nivel del contenido, muestra su descontento, explica el por qué e incluso ofrece una propuesta en base a su postura. Todo eso sin insultar a nadie, además que la gente de Codely se lo tomó bien
Es interesante el uso de proyecciones por evitar los JOINS. Pero hay otra alternativa: Fragmentación (horizontal, horizontal derivada o vertical). Cuando surge la necesidad de eliminar o reducir los JOINS es por la cantidad de datos que tenemos en base de datos, que al aplicar ciertos filtros o agregaciones se ralentizan las lecturas. El problema que veo en las proyecciones es que se añade demasiada complejidad en la aplicación cuando podemos empujar esta responsabilidad hacia la infraestructura, gracias a la fragmentación.
Hola interesante tu comentario, pero no entiendo a que te refieres con fragmentación Osea sería como listar cada tabla por aparte y después filtrar los datos con código o algo así ? Lo siento si no soy muy técnico pero no entiendo mucho de esto
Hola @@jonathanbernal6980, te explico un poco: Me voy a basar en la fragmentación horizontal, que es la más sencilla. Imagina que tienes una tienda online que recibe pedidos desde España y México, y tienes una alta demanda, por lo que muchos usuarios se registran en la tienda para realizar sus compras. Tienes un equipo de marketing, que cuando empiezan a realizar consultas sobre los usuarios, les consume mucho tiempo y la empresa requiere que se optimice este proceso. Cuando investigas, encuentras una tabla de usuarios con el atributo País que contiene los valores: España, México, y el atributo Edad. Aquí, entra en juego la fragmentación. Se trata de fragmentar (dividir) la tabla de usuarios en particiones (fragmentos) más pequeños en base a las consultas que recibe la tabla. Por ello, hablas con el equipo de marketing de España y te indican que ellos buscan usuarios que pertenezcan a España y en diferentes rangos de edad: menores de 30 años, y mayores de 30 años (por simplificar el ejemplo). Pues con esta información, podrías fragmentar la tabla de la siguiente manera: P1 = PAIS = ESPAÑA AND EDAD < 30 P2 = PAIS = ESPAÑA AND EDAD > 30 P1 y P2 son los dos fragmentos a crear. Se trata de recoger los usuarios que pertenezcan a esas clausulas y almacenarlos en una base de datos diferente. Así cuando el equipo de marketing requiera obtener los usuarios, será más optimo por que se realizará un SELECT * FROM P1 o SELECT * FROM P2 en tablas con la mitad de los datos, en lugar de un SELECT * FROM USUARIOS WHERE ... donde hay miles y miles de usuarios. Es importante mencionar que los fragmentos se crean en diferentes nodos, es decir, bases de datos en diferentes servidores. Ya que esta estrategia es más utilizada en entornos distribuidos. Te animo a que busques información sobre la fragmentación horizontal derivada, que es cuando la tabla tiene relaciones (JOINS) y requieres optimizarlos y sobre la vertical, que se trata de fragmentar en base a los atributos de la tabla (esto es un poco más complejo). Al final, esto es otra alternativa para optimizar las consultas en entornos que se requiera. Depende del problema, te convendrá más una alternativa que otra. Un saludo!!
@@jonathanbernal6980 creo que se refiere a particionar las tablas. Varios motores de BD permiten la particion de una tabla en base a un criterio, esto con el fin de que las escrituras y lecturas puedan ser más óptimas. La lógica de partición la maneja la propia BD así que sería casi transparente para la aplicación lo que sucede. Peerooo, hay que saber particionar, una mala estrategia puede empeorar el rendimiento o simplemente no ayudar en nada
@@jonathanbernal6980 con fragmentación me refiero a particionar (fragmentar) una tabla en tablas más pequeñas. Por ejemplo, la fragmentación horizontal divide los datos en función de sus valores, y las consultas que se realizan. Por ejemplo, si tuviésemos una tabla donde almacenamos usuarios de diferentes países, podríamos fragmentarla según cada valor del atributo país: una tabla para los usuarios de España, otra para los de México... etc. Esto hace que si una empresa es internacional, y alguno de sus departamentos de España necesita recuperar los usuarios de España, solo atacaría a la tabla de usuarios españoles. Es un ejemplo muy sencillo, normalmente se hace un estudio de que consultas se realizan a tablas relevantes y se fragmentan según las diferentes clausulas. Y la fragmentación horizontal derivada es cuando la tabla tiene relaciones y la vertical trata de dividir según los atributos de la tabla. Hay ciertas condiciones que cumplir, y está pensando para entornos distribuidos donde cada tabla estaría en un nodo diferente, es decir, una base de datos diferente en otro servidor. Pero es una alternativa que se utiliza mucho cuando queremos optimizar lecturas. El tema es extenso, podrías buscar mas información si te interesa. Por cierto, te respondí antes de este comentario y por alguna razón no se ha guardado...
No les han enseñado a usar indices y los tipos de inner que existen tampoco en usar las 4 formas normales por eso se espantan con un inner join de dos tablas
Excelente !! justo buscando buenas prácticas para mejorar el desarrollo de aplicaciones completas (de front a back a DB a server conf), me sumo a todos sus videos Gracias totales !
en este video se aplica la frase: "como usar un cañón para matar un mosquito" jajaj. Recuerden siempre el acrónimo K.I.S. por algo existe! agregar demasiada complejidad innecesaria es una mala práctica
Solo aplicaria para aplicaciones que vayan a utilizar gran cantidad de datos, necesiten tiempos de respuesta muy altos y sean distribuidos? O cuales serian los casos de uso? dado que con el uso de joins e indices podria mantenerse una aplicacion de pequeña o mediana escala.
No vale la pena evitar los Joins con tanto código intermedio, de primera ir por postgres y darle buenos recursos y hacer joins con tablas de millones de registros no será un problema. Tengo un sistemas desplegados con PHP7, Symfony y postgres con mas de 200 tablas y muchas con más de 64 millones de tupla y consultas de multiples joins a veces hasta 5 tablas a la ves se ejecutan en milisegundos (menos de 100). No es significativo complejisar tanto el sistema para ganar unos milisegundos no percetibles al usuario. Una variante es optimizando a niveld e base de datos la informacion usando indices, trigers, vistas, procedimientos que todo esos e ejecutará miles de veces más rapido que todo lo que se pueda haacer en codigo en la app hechas con lenguajes interpretados en el backend.
Ya que solemos hablar tanto de "casos de uso", podrian hablar de los casos de uso donde este enfoque se justifica. Y también sumaria casos de éxito aplicando esto que sugieren. Pd: quizas sus joins fuera mas performantes si usaram bigint en lugar de strings para las claves
1 Yo lo dejo con la vista. 2 usar bdd nosql 3 mantener una tabla con los datos listos a mostrar, actualizandola cada vez que se edita una dependencia. Fin. No se. Tendria que ver el caso de uso para poder gastar ese tiempo.
Las bases de datos relacionales están especialmente diseñadas para hacer joins muy eficientemente. Yo he visto procedimientos PL/SQL con for anidados para no hacer joins
Gracias por recuperar el gran valor o importancia de las vistas materializadas. Han dando un golpe sobre la mesa callandole la boca a muchas personas de negocio y algunos de infra que no quieren usar vistas materializadas cuando siempre existieron para mejorar performance.
@@lluismf En muchas aplicaciones la proporción de lectura es muy superior a la de escrituras, por lo que sí tiene sentido que mejore el performance en general, a pesar de que la carga se la lleve la escritura, ya que esta es en menor medida
La teoria es muy bonita... Product owner: Pueden añadir el año de publicacion en la web? Devs: si, pero nos va a llevar un par de meses, porque tenemos que añadir un nuevo campo, copiar los campos de una tabla a otra.... (millones de rows, porque si el join es lento es una tabla con millones de datos) Y la fiesta que se va a montar el dia que fallen los eventos y se desincronicen los datos. Si tu tus joins son lentos por la cantidad de datos de una tabla, hay que replantear como escalar la base de datos
Por tanto a través de las proyecciones tienes duplicidad de las entidades entre los diferentes contextos de tu aplicación, pierdes velocidad de escritura pero ganas velocidad de lectura. Lo que sí me entra la duda de se podrían encontrar race conditions cuando el guardado es más lento que la próxima consulta con alta demanda de peticiones. Muy buen vídeo cracks!
Yo por lo general uso joins 10 y hasta 20 tablas y algunas con billones de registros y no hay problemas. La verdad tengo muchas dudas dónde no conviene joins
6:45 las vistas que contienen joins no permiten inserts. Podrías aclarar a que os estais refiriendo con lo del ",momento de escritura"? Por otra parte deberias crear la vista con grant opcion, en mi opinión. Saludos.
Entonces ustedes no recomiendan utilizar join en tablas con grandes volúmenes de datos, hablamos de tablas con mas de 40 millones de registros, ahora si es imposible evitar no usar los join, que tipo de join recomiendan utilizar left join o inner join?
Muy buena solucion pero todo depende del volumen de eventos que tengas que sincronizar y las necesidades del otro contexto... si al final se meten libros y autores nuevos no muy frecuentemente o simplemente el contexto shop no necesita las actualizaciones en tiempo real, creo que la mas rentable es la vista materializada sobre todo por la cantidad de trabajo a nivel de ingenieria que te ahorras, porque al final el tamaño de los datos es lo de menos, pagas algo mas a final de mes y apañao. Otra posible solucion seria utilizar un patron gateway, yo lo he implementado en algunos proyectos usando GraphQL y va MUY bien
Aburrido. Mejor usar una cola, un dispatcher de eventos, un microservicio que consuma la cola, mejor si es una lambda, todo con DDD, sin acoplamiento y usando DI. Más cool, más caro e inmantenible, pero mas cool
¿Qué pasa si en el futuro necesito añadir una nueva vista que también requiere esos datos de los libros (para un contexto diferente del de shop)? Me imagino que tendría que reenviar todos los eventos de nuevo o ¿hay alguna alternativa mejor? Pensando en otro caso similar ¿qué pasaría si ahora al crear un libro requiero otra propiedad obligatoria y también esa propiedad debe de ir en ShopBook? O incluso una propiedad que ya existía en el libro en Backoffice pero que ahora quiero que se muestre en ShopBook, ¿eso cómo se manejaría?
+1 Estaba por redactar también esas preguntas para el caso de proyecciones, hice bien en buscarlos primero en los comentarios Para complementar, sobre la opción de proyecciones quiero poner como ejemplo el caso de los libros que estuvo en el vídeo, donde se quiere poner si el autor está vivo. En el ejemplo existe un atributo "authorIsAlive", el cual es un booleano, pero al mostrarlo en la tienda, ahora se requiere que se muestre indicando si el autor está "vivo" o "viva", por lo que para saber eso se necesitaría guardar también el género del autor. Y a esto le quiero agregar que si ya se han estado registrando libros en la aplicación desde hace más de 5 años y se requiere que a esos registros también se muestre el género del autor ¿cómo se solucionaría esa problemática? Supongamos que tenemos mucha data
@@ferriss_ sí ese que comentas es otro buen ejemplo del problema de esto. Lo de relanzar los eventos podría ayudar, pero está bastante salvaje si se tienen cientos de miles de registros, además incluso puede que para hacerlo se tengan que almacenar dichos eventos, pero en ese caso ya llegaríamos a EventSourcing y eso es todavía más complicado.
Si un libro tiene N autores y M generos, el query hara un producto cartesiano por lo que hacer un triple join tiene muy poco sentido. Si tiene 2 autores y 3 generos, un libro retornara 6 filas. Not good.
Entonces necesitaria 3 eventos de dominio diferente 1 para book otro para el autor y otro para el genero, porque como ya se menciono, son contextos diferentes y si no se tratan como shared kernel no podria como usarlos, a no ser que emita la informacion tambien en algun momento de los autores, porque como mas podria sincronziar si son infraestructura diferente, creo que le falto un pedazo al video .
Tengo una duda, si en algún momento modificas el título de un género, por ejemplo de ficción a ciencia ficcion, habría que ir por toda la db de shopbook actualizando el genreTitle? O como se haría de una forma eficiente? Y si en tu app tienes trafucciones a x idiomas en el género ahi que habria que hacer
En el primer metodo (Repository) al final estan usando JOINs ? No era la idea no usarlos ? Critica constructiva: creo que van muy rapido en el desarrollo de las explicaciones
Estas proyecciones o como yo los llamo, modelos de lectura, han sido un dolor de muelas en el proyecto en el que estoy trabajando. Si tu aplicación permite asincronizar la actualización de estos datos puede ser una opción. Pero si necesitas que todo sea sincrono con la transacción, acabas teniendo requests de lectura muy eficientes pero Post/Patches que se hacen eternos.
Es que es como tu dices. La actualización de la tabla que vas usar para la proyección, se tiene que actualizar asíncronamente en una cola, cuando la transacción de tu POST/PATCH haya terminado. Si lo haces síncrono, lo que estás ganando por un lado lo pierdes por el otro.
No vale la pena considerando la existencia de claves primarias, foraneas e indices. La unica forma donde sale rentable desnormalizar una tabla es si tienes que hacer 4+ Join para llegar a un atributo (e inclusive para eso existen mejores estrategias). Por otro lado el orden de los filtros definidos en el where permiten ir prefiltrando los datos así que invertiria más tiempo depurando una consulta con las diferentes herramientas de optimización que evitar joins limitando la escalabilidad de la aplicación, usando un motor de base de datos al 10% de sus capacidades, complejizando innecesariamente el código y de seguro para la mayoria de esos casos es mejor tener caché por el lado del servidor.
Exacto, aumenta la complejidad innecesariamente, pero eso en el caso de aplicaciones que no tienen mucho tráfico/peticiones y/o un alto volumen de datos. En el momento en que se ve que los servidores de la bd no aguantan a pesar de que autoescalan y que ya se hicieron varios tipos de optimizaciones, o cuando se está volviendo muy caro el procesamiento de la bd, es ahí cuando esto cobra sentido. Y como la mayoría de personas aún no se encuentra con esa problemática dicen cosas tipo: "Próximo vídeo: cómo no usar SELECT en las consultas". Aunque otros también lo dicen en son de broma sana a pesar de ya tener esa experiencia.
@@ferriss_ Entiendo tu punto y es interesante, pero eso abre un debate sobre infraestructura totalmente diferente. Conozco muy pocos hosting/servicios que cobren o tengan limites de consultas o "procesamiento" de la base de datos (Pero existen). Además, "no aguantar" en un servicio ya sea cloud o no, es un problema en la elección del proveedor de servicios/selección de infraestructura en comparación a las necesidades reales. No puedes esperar hacer un select en 3Mil millones de registros con un cloud de 8GB de ram ya sea de manera eficiente o inclusive eficaz puede quedar corto. Si estás manejando esos volumenes de datos ni siquiera estás pensando en una base de datos relacional tradicional como unica opción. Para esos volumenes de datos hay que manejar toda una estructura y arquitectura por detrás utilizando cluster, procesos de ETL, bases de datos complementarias (incluida no relacionales y clave-valor), motores de busqueda, otras tecnologias como hadoop, spark y al final del dia tienes construido un buen data lake o data warehouse distribuido en una infraestructura acorde a esos volumenes de datos. Algunas empresas que generan muchos datos y no pueden pagar la infraestructura optan por fraccionar sus datos teniendo solo los más recientes en producción y respaldando los antiguos, pero es complejo que una empresa diga "Oh, genial, juntemos 30 tablas en una sola con 500 columnas para solo hacer un select" (Si, es un comentario extremista). Aún así todo siempre dependerá de las necesidades, en el desarrollo de software nunca habrá una receta magica para todos los casos de uso
Desinformación pura y dura. Esto a alguien experto le puede hacer gracia,pero a una persona que está aprendiendo le hace mas mal que bien. Ejemplo de cómo aplicar la sobre arquitectura de la forma mas creativa posible. Conclusión: USA JOINS (Y BOFETADA DE BATMAN)
Disculpen mi crítica, pero esto no es rentable. Imagínense que tengas 400 u 800 tablas 😓... y luego ese viaje de trabajo por cada tabla, además de que el código del middleware se hace más grande. La lógica del negocio la puedes implementar con Packages/Store procedures/Functions y luego desde el middleware (o quien sea que se vaya a conectar según tu "patrón de diseño" 😕) solo llamas las rutinas según tu necesidad con ODBC/JDBC/etc etc, así es como se trabaja en la arquitectura de 3 niveles señores. Recordemos que la idea no es saturar el servidor con millones de instrucciones redundantes para hacer algo muy simple 🤦🏻♂️🤦🏻♂️🤦🏻♂️ y menos si tu sistema atenderá cientas, miles o decenas de miles de conexiones simultáneas.
@@boraolim Veo que no entendiste porqué he respondido a este video, amigo. Aquí no estoy hablando de juguetes, estoy hablando como un DBA y administrador de servidores, performance vs consumo de recursos, tiempos de respuesta, etc etc etc. Si vas a montar una paginita o una aplicación diminuta que diga "Hola mundo" pues usas tus herramientas predilectas y lo que quieras, pero si montarás algo serio pues no puedes obligar al equipo de desarrollo a hacer chorrociento trabajo por cada tabla y cada campo y de ñapa obviando el uso de sql 🤦🏻♂️... ¡si existe es por algo!. He sido DBA por una década, admin de N tipos de servidores distintos, desarrollador de middlewares y aplicaciones con transmisión masiva de datos sensibles a traves de medios inseguros y canales multiplexados... por eso, si te digo que es una idea absurda es porque sencillamente es así, no porque yo quiera suponerlo. Tampoco expongo esto por ego alguno.
Y si simplemente se cambia la consulta para usar un sub-select en vez de Joins? SELECT b.id, b.name, (SELECT a.name FROM author a WHERE a.id = b.author_id) as author_name, (SELECT g.name FROM genre g WHERE g.id = b.genre_id) as genre_name FROM book b Con los índices apropiados en cada tabla, el motor de base de datos es lo suficientemente inteligente para generar el plan de ejecución la primera vez y reutilizarlo a futuro, mejorando el rendimiento al no tener que hacer cruces con Joins.
A nivel Sql, los sub select rinden peor, mucho peor que los joins, de hecho, es recomendable que ni se usen en aplicaciones normales. Solo tienes que mirar el plan de ejecución y su I/O y nunca más lo vas a querer usar
Además que la mayoría de motores de base de datos no suelen optimizar subselects, y es posible que a veces ni lleguen a utilizar índices si la subselect es muy compleja.
Las subconsultas se ejecutan por cada fila, es decir, si tienes 1000 filas con una subconsulta estarias ejecutando 1001 consultas. Inviable en set de datos muy grandes aunque algunos motores de db lo tengan un poco más optimizado
El impacto de un subselect es aun peor que el de los joins. Lo peor que se podría hacer es eso. Aun asi la solución que proponen es puntual para casos particulares
@@chiquito.y.panzon Exacto, un subselect solo se usa cuando necesitamos un campo extra en la consulta que muy poco o nada tiene que ver con los Joins empleados y que en cuyo caso sería más costoso añadirle ese cruce allí también, de resto lo mejor es filtrar cada tabla si es posible y el resultado de ese filtro se cruza con las otras filtradas.
Muy bonito hasta que te das cuenta que hacer vistas te "ata" a usar una base de datos especifica y que cuando quieras cambiarte de motor de base de datos habrá que copiarse las vistas/store procedures/funciones que no siempre va a ser compatible, antes de inventar cosas hay que pensar a futuro, te evitas un join a cambio de "casarte" con una db. Mantengan las cosas simples en lugar de inventarse cosas para verse "pro".
En la practica cambiar el motor de base de datos en un proyecto en producción es algo muy rebuscado. Además, la tendencia de hoy es desarrollar con ORM, pocas empresas siguen utilizando SP, Trigger y Vistas para el ciclo de vida de una aplicación (A no ser que sean proyectos muy antiguos). Estamos de acuerdo en que verse "pro" y agregar una capa de dificultad extra al proyecto no tiene sentido. Como dijo el tio bob en el libro de arquitectura limpia... "Muchas veces el exceso de ingenieria es peor que no tener ingenieria" (o algo así, no recuerdo el literal).
Te falta mucho contexto y estas patinando demasiado en la respuesta. Para el caso de uso que dices, lo recomendable es hacer una tabla nueva, con los datos replicados que necesitas para la query de lectura en la proyección, así luego la migración es más sencilla. Que lo normal es tenerlo en una base de datos separada, porque fíjate que cosas es algo que necesita un contexto/cliente específico. Supongo que en tu caso, el que decidió usar una vista, lo hizo con todo la buena intención del mundo y no sabía que a largo plazo iba tener que migrar a otro motor de base de datos. Típicos problemas de no pensar las cosas bien antes de hacerla, y en muchos casos ignorar como se tienen que hacer. Problemas del primer mundo
Ya no se si hacen esto de manera intencional para ganar vistas generadas por "polemicas" y esas cosas porque ya no tiene con que hacer dinero o es que de verdad creen que saben de base de datos. Wtf.
Si es para ganar views e interacciones el video y el titulo están genial, pero no explica nada. El problema no es usar JOIN el problema está en la optimización de los mismos.
Interesante pero el titulo del video de mas grandilocuente que lonque estan explicando, flojo en relacion al titulo. Igualmente, sigan asi que educar es mucho mejor que hacer videos de regalón. Abrazo grande
Tiempo perdido. Eso es este video. Tras 24 años dedicado al desarrollo, si me dices que elija entre escribir una query con joins o picar 13 clases en codigo, yo creo que la elección es clara. A ver quién mantiene eso ante un cambio como, por ejemplo añadir un campo a dos entidades distintas. Esto es teoría para estudiantes impresionables. En el mundo real escribes una query en 5 minutos, y pasas a la siguiente tarea. Otros videos que he visto si me han parecido utiles o instructivos, pero este se fundamenta en hacer difícil lo sencilllo. Inservible en la vida real. Y se atreven a decir que los joins son costosos. Ignorancia sobre bases de datos.
Hicimos un directo respondiendo comentarios con puntos de vista sobre este vídeo similares al que expones. Si te interesa el tema: Debate: Cómo y cuándo evito usar JOINs | #laFunción 9x24 th-cam.com/users/liveezeU-MaKH1s
han tirado por la borda mi vida de programador, que buena idea; ahora como recupero el tiempo perdido modelando las pinches bases de datos ? jajajajaja
Directo debatiendo sobre los comentarios de este vídeo: th-cam.com/video/ezeU-MaKH1s/w-d-xo.html
Curso Modelado del dominio: Proyecciones bit.ly/curso-proyecciones
Próximo video: Cómo evitar usar SELECT en mis consultas. 🐧
ah jaja, estamos sincronizados
Buenísima 😂. O como no usar relaciones en una base de datos relacional 😂😂
c mamó😂
si cacheas la info entonces evitas de hacer un SELECT jajaja
Jaja
Product Owner: Cuánto te demoras en mostrar la tabla en la página web
Desarrollador: Como 3 meses
Product Onwer: Qué? Por qué tanto
Desarrollador: Es que mira ....
Y muchos dicen: no way! El cliente lo quiere asap!
Cada día nos complicamos más, quisiera ver un proyecto real, funcionando y siendo mantenido con todas las buenas prácticas actuales
Totalmente de acuerdo, como que solo se ven por parte pero nunca todo integrado.
Cuesta más el collar que el perro
Por eso este collar no es para cualquier perro ☺️
Y eso que hay que sumarle las 4 colas para la confiabilidad... 3 de re intento y la death leather 😅
@@Bleibruk Por eso está solución, no es para todo el mundo ni aplica al 95% de los casos de usos. Sólo los que tengan un problema de rendimiento preocupante en algunos de sus endpoints, podrá llegar aplicar algo como esto.
De todas formas, evitar el uso de joins es una práctica bastante extendida cuando se hace DDD. Pero lo dicho, esto no se da ni se dará en la gran mayoría de empresas, solo una minoría puede llegar aplicar algo como esto.
@@kuja69 eso es lo que trato de decir 😊
Buen punto. El jueves que viene lo comentamos en directo😊 th-cam.com/video/ezeU-MaKH1s/w-d-xo.html
opino lo mismo, para ganar cuántos ms? es más práctico hacer un store procedure para cada caso en concreto que agregar tanta complejidad para q vaya 50ms más rápido
Gracias, gracias por el contenido, muy bueno y aplicable. Únicamente los títulos de los videos no los veo para nada acorde al contenido. Por ejemplo, acá están entregando una master class (y en otros videos) muy profesional, contenido de alto nivel, muchos jr/mid no entenderían estos conceptos, ni las preocupaciones a los problemas que resuelvan acá. Considero el título no hace justicia al contenido, yo por ejemplo entré negativo (como muchos otros que comentan risiblemente) esperando escuchar alguna burrada, pero sorpresa: No, es contenido excelente! Obviamente, el canal es de ustedes y les ponen los títulos que quieren a los videos, pero si algún día busco: Como mejorar rendimiento de consultas en DB relacionales, seguro este video nunca saldrá. Por lo que me imagino este conocimiento no se indexaría, más bien serviría para la primera semana y luego olvidado. Personalmente, dejaría títulos extraños para reels/tiktoks/etc. Mi resumen: Conocimiento profundo escondido en títulos dudosos.
Mejor título: Cómo y cuándo evito usar JOINs
Concuerdo al 100%
Gracias por el feedback. Aplicado al directo de seguimiento del vídeo 😊 th-cam.com/video/ezeU-MaKH1s/w-d-xo.html
para eso no hubieras dicho nada man! se constructivo!
@@norbertocontreras4725 Yo creo que es un feedback constructivo, reconoce el nivel del contenido, muestra su descontento, explica el por qué e incluso ofrece una propuesta en base a su postura. Todo eso sin insultar a nadie, además que la gente de Codely se lo tomó bien
Bueno, tienes razón, por mi parte en cuanto el título del video sabía que era algo para mejorar el performance de un sistema
Es interesante el uso de proyecciones por evitar los JOINS. Pero hay otra alternativa: Fragmentación (horizontal, horizontal derivada o vertical). Cuando surge la necesidad de eliminar o reducir los JOINS es por la cantidad de datos que tenemos en base de datos, que al aplicar ciertos filtros o agregaciones se ralentizan las lecturas. El problema que veo en las proyecciones es que se añade demasiada complejidad en la aplicación cuando podemos empujar esta responsabilidad hacia la infraestructura, gracias a la fragmentación.
Hola interesante tu comentario, pero no entiendo a que te refieres con fragmentación
Osea sería como listar cada tabla por aparte y después filtrar los datos con código o algo así ?
Lo siento si no soy muy técnico pero no entiendo mucho de esto
Hola @@jonathanbernal6980, te explico un poco:
Me voy a basar en la fragmentación horizontal, que es la más sencilla. Imagina que tienes una tienda online que recibe pedidos desde España y México, y tienes una alta demanda, por lo que muchos usuarios se registran en la tienda para realizar sus compras. Tienes un equipo de marketing, que cuando empiezan a realizar consultas sobre los usuarios, les consume mucho tiempo y la empresa requiere que se optimice este proceso. Cuando investigas, encuentras una tabla de usuarios con el atributo País que contiene los valores: España, México, y el atributo Edad.
Aquí, entra en juego la fragmentación. Se trata de fragmentar (dividir) la tabla de usuarios en particiones (fragmentos) más pequeños en base a las consultas que recibe la tabla. Por ello, hablas con el equipo de marketing de España y te indican que ellos buscan usuarios que pertenezcan a España y en diferentes rangos de edad: menores de 30 años, y mayores de 30 años (por simplificar el ejemplo).
Pues con esta información, podrías fragmentar la tabla de la siguiente manera:
P1 = PAIS = ESPAÑA AND EDAD < 30
P2 = PAIS = ESPAÑA AND EDAD > 30
P1 y P2 son los dos fragmentos a crear. Se trata de recoger los usuarios que pertenezcan a esas clausulas y almacenarlos en una base de datos diferente. Así cuando el equipo de marketing requiera obtener los usuarios, será más optimo por que se realizará un SELECT * FROM P1 o SELECT * FROM P2 en tablas con la mitad de los datos, en lugar de un SELECT * FROM USUARIOS WHERE ... donde hay miles y miles de usuarios.
Es importante mencionar que los fragmentos se crean en diferentes nodos, es decir, bases de datos en diferentes servidores. Ya que esta estrategia es más utilizada en entornos distribuidos. Te animo a que busques información sobre la fragmentación horizontal derivada, que es cuando la tabla tiene relaciones (JOINS) y requieres optimizarlos y sobre la vertical, que se trata de fragmentar en base a los atributos de la tabla (esto es un poco más complejo).
Al final, esto es otra alternativa para optimizar las consultas en entornos que se requiera. Depende del problema, te convendrá más una alternativa que otra.
Un saludo!!
@@jonathanbernal6980 creo que se refiere a particionar las tablas. Varios motores de BD permiten la particion de una tabla en base a un criterio, esto con el fin de que las escrituras y lecturas puedan ser más óptimas. La lógica de partición la maneja la propia BD así que sería casi transparente para la aplicación lo que sucede. Peerooo, hay que saber particionar, una mala estrategia puede empeorar el rendimiento o simplemente no ayudar en nada
@@Bleibruk Me quedo más claro gracias
@@jonathanbernal6980 con fragmentación me refiero a particionar (fragmentar) una tabla en tablas más pequeñas. Por ejemplo, la fragmentación horizontal divide los datos en función de sus valores, y las consultas que se realizan. Por ejemplo, si tuviésemos una tabla donde almacenamos usuarios de diferentes países, podríamos fragmentarla según cada valor del atributo país: una tabla para los usuarios de España, otra para los de México... etc. Esto hace que si una empresa es internacional, y alguno de sus departamentos de España necesita recuperar los usuarios de España, solo atacaría a la tabla de usuarios españoles. Es un ejemplo muy sencillo, normalmente se hace un estudio de que consultas se realizan a tablas relevantes y se fragmentan según las diferentes clausulas. Y la fragmentación horizontal derivada es cuando la tabla tiene relaciones y la vertical trata de dividir según los atributos de la tabla. Hay ciertas condiciones que cumplir, y está pensando para entornos distribuidos donde cada tabla estaría en un nodo diferente, es decir, una base de datos diferente en otro servidor. Pero es una alternativa que se utiliza mucho cuando queremos optimizar lecturas. El tema es extenso, podrías buscar mas información si te interesa. Por cierto, te respondí antes de este comentario y por alguna razón no se ha guardado...
Próximo video: Cómo evitar usar base de datos.
xD
El próximo vídeo será directo debatiendo sobre alguno de los puntos de los comentarios 😊 th-cam.com/video/ezeU-MaKH1s/w-d-xo.html
@@CodelyTV jaja que bueno que se tomen como se debe las satiras 🙏🏻 buen contenido estimados, saludos desde Chile 🙌🏻
Me imagino q como base corporativa van a utilizar un archivo csv 😂
@@theroot6495 Habrá que reinventar las bases de datos.
No les han enseñado a usar indices y los tipos de inner que existen tampoco en usar las 4 formas normales por eso se espantan con un inner join de dos tablas
Próximo vídeo: Como programar usando NotePad para mejorar tu rendimiento
Excelente !! justo buscando buenas prácticas para mejorar el desarrollo de aplicaciones completas (de front a back a DB a server conf), me sumo a todos sus videos
Gracias totales !
en este video se aplica la frase: "como usar un cañón para matar un mosquito" jajaj. Recuerden siempre el acrónimo K.I.S. por algo existe! agregar demasiada complejidad innecesaria es una mala práctica
expertos en complicar lo simple
Gracias a este video me entero que lo que vengo haciendo en mis proyectos hace año y algo se llama proyecciones jaja
Título del próximo video:
Por qué no uso "SELECT" en mis consultas SQL. 😄😜
Excelente informacion y clara, muchas gracias.
Seria interesante ver algo similar en optimizacion con base de datos no relacionales.
Saludos.
evito usar joins usando bd no sqls que generalmente se usa para controlar gran cantidad de data
Buenísimo el enfoque del video... 🎉 Que temaso
Ya tienes que tener millones y millones de registros y muchas peticiones para que salga rentable una solución así. Aunque muy bien explicado.
Solo aplicaria para aplicaciones que vayan a utilizar gran cantidad de datos, necesiten tiempos de respuesta muy altos y sean distribuidos? O cuales serian los casos de uso? dado que con el uso de joins e indices podria mantenerse una aplicacion de pequeña o mediana escala.
Me encantó, no sabía lo de las proyecciones.
Creo que el titulo del video esta mal, al final los joins esta en la vista. Y bien dicho al final, depende de para que proyecto aplicar...
Muy bueno chicos! super interesante.
Cada vez más rebuscados.
Brutal como lo explican 🤯🤯🤯
El título del vídeo puede ocasionar confusión; pero se entiende la idea. Buen contenido, gracias 👍
No vale la pena evitar los Joins con tanto código intermedio, de primera ir por postgres y darle buenos recursos y hacer joins con tablas de millones de registros no será un problema. Tengo un sistemas desplegados con PHP7, Symfony y postgres con mas de 200 tablas y muchas con más de 64 millones de tupla y consultas de multiples joins a veces hasta 5 tablas a la ves se ejecutan en milisegundos (menos de 100). No es significativo complejisar tanto el sistema para ganar unos milisegundos no percetibles al usuario. Una variante es optimizando a niveld e base de datos la informacion usando indices, trigers, vistas, procedimientos que todo esos e ejecutará miles de veces más rapido que todo lo que se pueda haacer en codigo en la app hechas con lenguajes interpretados en el backend.
Ya que solemos hablar tanto de "casos de uso", podrian hablar de los casos de uso donde este enfoque se justifica. Y también sumaria casos de éxito aplicando esto que sugieren.
Pd: quizas sus joins fuera mas performantes si usaram bigint en lugar de strings para las claves
Sí sería genial que hubiera casos de éxito. Y ellos usan UUID para que el cliente los genere, con eso mejoran la idempotencia
1 Yo lo dejo con la vista.
2 usar bdd nosql
3 mantener una tabla con los datos listos a mostrar, actualizandola cada vez que se edita una dependencia.
Fin. No se. Tendria que ver el caso de uso para poder gastar ese tiempo.
Proximo video: Como usar una base de datos evitando el overhead de los datos y la propia base.
Tomamos nota de ese título ✍️😂
Las bases de datos relacionales están especialmente diseñadas para hacer joins muy eficientemente. Yo he visto procedimientos PL/SQL con for anidados para no hacer joins
he pensado lo mismo pero creo que el foco del problema está en que gestionar eso a nivel de código bajo arquitectura hexagonal no queda "bonito"
Gracias por recuperar el gran valor o importancia de las vistas materializadas. Han dando un golpe sobre la mesa callandole la boca a muchas personas de negocio y algunos de infra que no quieren usar vistas materializadas cuando siempre existieron para mejorar performance.
Impactan en la escritura. Y no dejan de ser una chapuza.
@@lluismf En muchas aplicaciones la proporción de lectura es muy superior a la de escrituras, por lo que sí tiene sentido que mejore el performance en general, a pesar de que la carga se la lleve la escritura, ya que esta es en menor medida
@@ferriss_ Precisamente por eso, si hay muchas escrituras hacer vistas materializadas no es buena opción.
@@lluismf Lo escribí al revés por equivocación. 😂 Deja lo actualizo
Ahora sí
Necesito que tipo de Diapositivas se usa para la explicación del video. no me parece que sea PowerPoint. Muchas gracias y muy buen video @codelyTV
La teoria es muy bonita...
Product owner: Pueden añadir el año de publicacion en la web?
Devs: si, pero nos va a llevar un par de meses, porque tenemos que añadir un nuevo campo, copiar los campos de una tabla a otra.... (millones de rows, porque si el join es lento es una tabla con millones de datos)
Y la fiesta que se va a montar el dia que fallen los eventos y se desincronicen los datos.
Si tu tus joins son lentos por la cantidad de datos de una tabla, hay que replantear como escalar la base de datos
Tiempo para normalizar vs ahorro de costo de servidor y tiempo de consulta 🧐
Y después...como evitar ORDER BY...guardar todo en una BD en el orden que mostraras en tu interfaz (y no permitir al user ordenar)
Como evitar group by... asi sucesivamente
Jajaja "tendremos N tablas con los diferentes órdenes que puede solicitar el usuario"
Excelente!
Por tanto a través de las proyecciones tienes duplicidad de las entidades entre los diferentes contextos de tu aplicación, pierdes velocidad de escritura pero ganas velocidad de lectura.
Lo que sí me entra la duda de se podrían encontrar race conditions cuando el guardado es más lento que la próxima consulta con alta demanda de peticiones.
Muy buen vídeo cracks!
Yo por lo general uso joins 10 y hasta 20 tablas y algunas con billones de registros y no hay problemas. La verdad tengo muchas dudas dónde no conviene joins
Pero, en el backoffice, el repositorio GenderRepor y AuthorRepo no existen?
Cómo si no se van a saber esos UUIDs de cada genero autor?
Sollo les entendi hasta las vistas pero gracias por el video
6:45 las vistas que contienen joins no permiten inserts. Podrías aclarar a que os estais refiriendo con lo del ",momento de escritura"? Por otra parte deberias crear la vista con grant opcion, en mi opinión. Saludos.
Buen video🎉🎉🎉
Entonces ustedes no recomiendan utilizar join en tablas con grandes volúmenes de datos, hablamos de tablas con mas de 40 millones de registros, ahora si es imposible evitar no usar los join, que tipo de join recomiendan utilizar left join o inner join?
Muy buena solucion pero todo depende del volumen de eventos que tengas que sincronizar y las necesidades del otro contexto... si al final se meten libros y autores nuevos no muy frecuentemente o simplemente el contexto shop no necesita las actualizaciones en tiempo real, creo que la mas rentable es la vista materializada sobre todo por la cantidad de trabajo a nivel de ingenieria que te ahorras, porque al final el tamaño de los datos es lo de menos, pagas algo mas a final de mes y apañao.
Otra posible solucion seria utilizar un patron gateway, yo lo he implementado en algunos proyectos usando GraphQL y va MUY bien
En la empresa donde trabajo la db tiene más de 500 tablas te imaginas hacer estás marañas por cada query
y si le meten un trigger al book para que cuando se cree ejecute con sp para que llene la otra tabla?
Aburrido. Mejor usar una cola, un dispatcher de eventos, un microservicio que consuma la cola, mejor si es una lambda, todo con DDD, sin acoplamiento y usando DI. Más cool, más caro e inmantenible, pero mas cool
Fragmentación, una tabla en la nube con los datos mas solicitados
Este video es ORO PURO.. sin embargo, hay gente que en lugar de agradecer se dedica a tirar sarcasmos.. que tristeza..
Es que es mejor saber modelar la base de datos, y asi usar bien los joins, puedes mover millones de registros con buen rendimiento
es que està mal titulado (a propòsito) y encima de algo que es simple lo hacen ultra complejo!
¿Qué pasa si en el futuro necesito añadir una nueva vista que también requiere esos datos de los libros (para un contexto diferente del de shop)? Me imagino que tendría que reenviar todos los eventos de nuevo o ¿hay alguna alternativa mejor?
Pensando en otro caso similar ¿qué pasaría si ahora al crear un libro requiero otra propiedad obligatoria y también esa propiedad debe de ir en ShopBook? O incluso una propiedad que ya existía en el libro en Backoffice pero que ahora quiero que se muestre en ShopBook, ¿eso cómo se manejaría?
+1
Estaba por redactar también esas preguntas para el caso de proyecciones, hice bien en buscarlos primero en los comentarios
Para complementar, sobre la opción de proyecciones quiero poner como ejemplo el caso de los libros que estuvo en el vídeo, donde se quiere poner si el autor está vivo. En el ejemplo existe un atributo "authorIsAlive", el cual es un booleano, pero al mostrarlo en la tienda, ahora se requiere que se muestre indicando si el autor está "vivo" o "viva", por lo que para saber eso se necesitaría guardar también el género del autor. Y a esto le quiero agregar que si ya se han estado registrando libros en la aplicación desde hace más de 5 años y se requiere que a esos registros también se muestre el género del autor ¿cómo se solucionaría esa problemática? Supongamos que tenemos mucha data
@@ferriss_ sí ese que comentas es otro buen ejemplo del problema de esto. Lo de relanzar los eventos podría ayudar, pero está bastante salvaje si se tienen cientos de miles de registros, además incluso puede que para hacerlo se tengan que almacenar dichos eventos, pero en ese caso ya llegaríamos a EventSourcing y eso es todavía más complicado.
Si un libro tiene N autores y M generos, el query hara un producto cartesiano por lo que hacer un triple join tiene muy poco sentido. Si tiene 2 autores y 3 generos, un libro retornara 6 filas. Not good.
¿Y si se evitan las capas o la poo y se optimiza el query?
Yo creo que hay casos donde esta es la mejor opción, claramente no en todos, pero sin duda puede ser válido en algún caso particular
Entonces necesitaria 3 eventos de dominio diferente 1 para book otro para el autor y otro para el genero, porque como ya se menciono, son contextos diferentes y si no se tratan como shared kernel no podria como usarlos, a no ser que emita la informacion tambien en algun momento de los autores, porque como mas podria sincronziar si son infraestructura diferente, creo que le falto un pedazo al video .
Pase a buscar Oro pero no lo encontre :v . Al final es obtener los datos de vistas materializadas? no entendi
hicieron demasiado complejo lo que es y debe ser simple jajaj
genios
Las vistascutilozandolas bien, ayidan bastante
Tengo una duda, si en algún momento modificas el título de un género, por ejemplo de ficción a ciencia ficcion, habría que ir por toda la db de shopbook actualizando el genreTitle?
O como se haría de una forma eficiente?
Y si en tu app tienes trafucciones a x idiomas en el género ahi que habria que hacer
Buen punto.
Cómo evitar utilizar variables cuando programa
Mmm.. soy de la vieja guardia... ese encolado con Rabbit me parece a querer repartir pizzas con un camión de 18 ruedas 🤷♂🤷♂
No lo asociaría tanto a ser “de la vieja escuela”, si no quizás a simplemente no haberlo necesitado 😊
metan todo eso en un nosql y ya.. jaja
Está muy bueno. Y hago un pedido. Pueden hablar un poco mas pausado ?, lo hacen muy rápido y es dificil seguirlos.
Si lo pongo el video en 0.75 de velocidad se resuelve ;)
Próximo video: cómo evito usar divs cuando estoy usando HTML
En el primer metodo (Repository) al final estan usando JOINs ? No era la idea no usarlos ?
Critica constructiva: creo que van muy rapido en el desarrollo de las explicaciones
Se. Rapidísimo. Incluso en 1x
Database.Infrastructure.Model.Repository.Facade.Service.Controller.Presentation.Print("Hola mundo")
Query Cache...
Estas proyecciones o como yo los llamo, modelos de lectura, han sido un dolor de muelas en el proyecto en el que estoy trabajando. Si tu aplicación permite asincronizar la actualización de estos datos puede ser una opción. Pero si necesitas que todo sea sincrono con la transacción, acabas teniendo requests de lectura muy eficientes pero Post/Patches que se hacen eternos.
Es que es como tu dices. La actualización de la tabla que vas usar para la proyección, se tiene que actualizar asíncronamente en una cola, cuando la transacción de tu POST/PATCH haya terminado. Si lo haces síncrono, lo que estás ganando por un lado lo pierdes por el otro.
joer pues te montas un cqrs y listo... pero vamos para esa parida no hace falta
Mejor moverse a mongo o alguna base nosql
😮😢
No vale la pena considerando la existencia de claves primarias, foraneas e indices. La unica forma donde sale rentable desnormalizar una tabla es si tienes que hacer 4+ Join para llegar a un atributo (e inclusive para eso existen mejores estrategias). Por otro lado el orden de los filtros definidos en el where permiten ir prefiltrando los datos así que invertiria más tiempo depurando una consulta con las diferentes herramientas de optimización que evitar joins limitando la escalabilidad de la aplicación, usando un motor de base de datos al 10% de sus capacidades, complejizando innecesariamente el código y de seguro para la mayoria de esos casos es mejor tener caché por el lado del servidor.
Exacto, aumenta la complejidad innecesariamente, pero eso en el caso de aplicaciones que no tienen mucho tráfico/peticiones y/o un alto volumen de datos. En el momento en que se ve que los servidores de la bd no aguantan a pesar de que autoescalan y que ya se hicieron varios tipos de optimizaciones, o cuando se está volviendo muy caro el procesamiento de la bd, es ahí cuando esto cobra sentido. Y como la mayoría de personas aún no se encuentra con esa problemática dicen cosas tipo: "Próximo vídeo: cómo no usar SELECT en las consultas". Aunque otros también lo dicen en son de broma sana a pesar de ya tener esa experiencia.
@@ferriss_ Entiendo tu punto y es interesante, pero eso abre un debate sobre infraestructura totalmente diferente. Conozco muy pocos hosting/servicios que cobren o tengan limites de consultas o "procesamiento" de la base de datos (Pero existen). Además, "no aguantar" en un servicio ya sea cloud o no, es un problema en la elección del proveedor de servicios/selección de infraestructura en comparación a las necesidades reales.
No puedes esperar hacer un select en 3Mil millones de registros con un cloud de 8GB de ram ya sea de manera eficiente o inclusive eficaz puede quedar corto. Si estás manejando esos volumenes de datos ni siquiera estás pensando en una base de datos relacional tradicional como unica opción. Para esos volumenes de datos hay que manejar toda una estructura y arquitectura por detrás utilizando cluster, procesos de ETL, bases de datos complementarias (incluida no relacionales y clave-valor), motores de busqueda, otras tecnologias como hadoop, spark y al final del dia tienes construido un buen data lake o data warehouse distribuido en una infraestructura acorde a esos volumenes de datos.
Algunas empresas que generan muchos datos y no pueden pagar la infraestructura optan por fraccionar sus datos teniendo solo los más recientes en producción y respaldando los antiguos, pero es complejo que una empresa diga "Oh, genial, juntemos 30 tablas en una sola con 500 columnas para solo hacer un select" (Si, es un comentario extremista).
Aún así todo siempre dependerá de las necesidades, en el desarrollo de software nunca habrá una receta magica para todos los casos de uso
@@chiquito.y.panzon Concuerdo completamente en lo que comentaste
Desinformación pura y dura. Esto a alguien experto le puede hacer gracia,pero a una persona que está aprendiendo le hace mas mal que bien. Ejemplo de cómo aplicar la sobre arquitectura de la forma mas creativa posible. Conclusión: USA JOINS (Y BOFETADA DE BATMAN)
no es esto como una especie de patrón de fachada? siento si he dicho una burrada 😆
Disculpen mi crítica, pero esto no es rentable. Imagínense que tengas 400 u 800 tablas 😓... y luego ese viaje de trabajo por cada tabla, además de que el código del middleware se hace más grande. La lógica del negocio la puedes implementar con Packages/Store procedures/Functions y luego desde el middleware (o quien sea que se vaya a conectar según tu "patrón de diseño" 😕) solo llamas las rutinas según tu necesidad con ODBC/JDBC/etc etc, así es como se trabaja en la arquitectura de 3 niveles señores.
Recordemos que la idea no es saturar el servidor con millones de instrucciones redundantes para hacer algo muy simple 🤦🏻♂️🤦🏻♂️🤦🏻♂️ y menos si tu sistema atenderá cientas, miles o decenas de miles de conexiones simultáneas.
Para cosas simples o de alto consumo existen Caché o REDIS. Eso fue lo que no pusiste atención amigo.
@@boraolim Veo que no entendiste porqué he respondido a este video, amigo. Aquí no estoy hablando de juguetes, estoy hablando como un DBA y administrador de servidores, performance vs consumo de recursos, tiempos de respuesta, etc etc etc. Si vas a montar una paginita o una aplicación diminuta que diga "Hola mundo" pues usas tus herramientas predilectas y lo que quieras, pero si montarás algo serio pues no puedes obligar al equipo de desarrollo a hacer chorrociento trabajo por cada tabla y cada campo y de ñapa obviando el uso de sql 🤦🏻♂️... ¡si existe es por algo!. He sido DBA por una década, admin de N tipos de servidores distintos, desarrollador de middlewares y aplicaciones con transmisión masiva de datos sensibles a traves de medios inseguros y canales multiplexados... por eso, si te digo que es una idea absurda es porque sencillamente es así, no porque yo quiera suponerlo. Tampoco expongo esto por ego alguno.
Excelente contenido! Saludos!
Y si simplemente se cambia la consulta para usar un sub-select en vez de Joins?
SELECT b.id, b.name, (SELECT a.name FROM author a WHERE a.id = b.author_id) as author_name, (SELECT g.name FROM genre g WHERE g.id = b.genre_id) as genre_name
FROM book b
Con los índices apropiados en cada tabla, el motor de base de datos es lo suficientemente inteligente para generar el plan de ejecución la primera vez y reutilizarlo a futuro, mejorando el rendimiento al no tener que hacer cruces con Joins.
A nivel Sql, los sub select rinden peor, mucho peor que los joins, de hecho, es recomendable que ni se usen en aplicaciones normales. Solo tienes que mirar el plan de ejecución y su I/O y nunca más lo vas a querer usar
Además que la mayoría de motores de base de datos no suelen optimizar subselects, y es posible que a veces ni lleguen a utilizar índices si la subselect es muy compleja.
Las subconsultas se ejecutan por cada fila, es decir, si tienes 1000 filas con una subconsulta estarias ejecutando 1001 consultas. Inviable en set de datos muy grandes aunque algunos motores de db lo tengan un poco más optimizado
El impacto de un subselect es aun peor que el de los joins. Lo peor que se podría hacer es eso. Aun asi la solución que proponen es puntual para casos particulares
@@chiquito.y.panzon Exacto, un subselect solo se usa cuando necesitamos un campo extra en la consulta que muy poco o nada tiene que ver con los Joins empleados y que en cuyo caso sería más costoso añadirle ese cruce allí también, de resto lo mejor es filtrar cada tabla si es posible y el resultado de ese filtro se cruza con las otras filtradas.
Buen video, quiza el titulo fue el que no le ayudo del todo
Muy bonito hasta que te das cuenta que hacer vistas te "ata" a usar una base de datos especifica y que cuando quieras cambiarte de motor de base de datos habrá que copiarse las vistas/store procedures/funciones que no siempre va a ser compatible, antes de inventar cosas hay que pensar a futuro, te evitas un join a cambio de "casarte" con una db. Mantengan las cosas simples en lugar de inventarse cosas para verse "pro".
En la practica cambiar el motor de base de datos en un proyecto en producción es algo muy rebuscado. Además, la tendencia de hoy es desarrollar con ORM, pocas empresas siguen utilizando SP, Trigger y Vistas para el ciclo de vida de una aplicación (A no ser que sean proyectos muy antiguos).
Estamos de acuerdo en que verse "pro" y agregar una capa de dificultad extra al proyecto no tiene sentido. Como dijo el tio bob en el libro de arquitectura limpia... "Muchas veces el exceso de ingenieria es peor que no tener ingenieria" (o algo así, no recuerdo el literal).
Te falta mucho contexto y estas patinando demasiado en la respuesta. Para el caso de uso que dices, lo recomendable es hacer una tabla nueva, con los datos replicados que necesitas para la query de lectura en la proyección, así luego la migración es más sencilla. Que lo normal es tenerlo en una base de datos separada, porque fíjate que cosas es algo que necesita un contexto/cliente específico. Supongo que en tu caso, el que decidió usar una vista, lo hizo con todo la buena intención del mundo y no sabía que a largo plazo iba tener que migrar a otro motor de base de datos. Típicos problemas de no pensar las cosas bien antes de hacerla, y en muchos casos ignorar como se tienen que hacer. Problemas del primer mundo
Ya no se si hacen esto de manera intencional para ganar vistas generadas por "polemicas" y esas cosas porque ya no tiene con que hacer dinero o es que de verdad creen que saben de base de datos. Wtf.
Nunca evitas el join, sino como construis el json?.
Si es para ganar views e interacciones el video y el titulo están genial, pero no explica nada. El problema no es usar JOIN el problema está en la optimización de los mismos.
Interesante pero el titulo del video de mas grandilocuente que lonque estan explicando, flojo en relacion al titulo. Igualmente, sigan asi que educar es mucho mejor que hacer videos de regalón.
Abrazo grande
pero que chorrada son estas????
Pura verborrea
Tiempo perdido. Eso es este video. Tras 24 años dedicado al desarrollo, si me dices que elija entre escribir una query con joins o picar 13 clases en codigo, yo creo que la elección es clara.
A ver quién mantiene eso ante un cambio como, por ejemplo añadir un campo a dos entidades distintas.
Esto es teoría para estudiantes impresionables. En el mundo real escribes una query en 5 minutos, y pasas a la siguiente tarea.
Otros videos que he visto si me han parecido utiles o instructivos, pero este se fundamenta en hacer difícil lo sencilllo. Inservible en la vida real. Y se atreven a decir que los joins son costosos. Ignorancia sobre bases de datos.
Hicimos un directo respondiendo comentarios con puntos de vista sobre este vídeo similares al que expones. Si te interesa el tema: Debate: Cómo y cuándo evito usar JOINs | #laFunción 9x24
th-cam.com/users/liveezeU-MaKH1s
Todos los videos son bait para encajarte cursos...
y qué esperas de una plataforma que se dedica a eso...
han tirado por la borda mi vida de programador, que buena idea; ahora como recupero el tiempo perdido modelando las pinches bases de datos ? jajajajaja