Debate: Cómo y cuándo evito usar JOINs |

Debate al respecto de Proyecciones, Vistas de base de datos, y JOINs
No siempre hace falta utilizar JOINs en tu código. Gracias a las proyecciones en nuestro código podemos ganar mucho rendimiento y mantenimiento (a costa, eso sí, de picar más código 😅).
La semana pasada publicamos un vídeo al respecto ( • Cómo evito usar JOINs ) y se generó una serie de comentarios con argumentos interesantes. En este directo nos centraremos en debatir al respecto de esos puntos.
﹤🍍﹥ Enlaces
├ 🎥 Suscríbete: kzbin.info...
├ 🔖 Cursos: bit.ly/codely-pro
├ 🔗 Recursos relacionados:
| ├ • Cómo evito usar JOINs
| ├ 📝 Curso Modelado del dominio: Agregados: pro.codely.com...
| └ 📝 Curso Modelado del dominio: Proyecciones bit.ly/curso-p...
└ 👋 Redes sociales:
├ / codelytv
├ / rafaoe
├ / javiercane
├ / codelytv
└ / codelytv

[@ChristianReyP]

Uno de los proyectos en los que estoy trabajando tiene un punto crítico de carga de datos muy alto en una página determinada. El modelado que tengo y las relaciones que están definidas (polimórficas, many to many, etc... y de varios niveles) hacían que la carga fuese un infierno. La solución en cuanto a una mejora de más de un 500% ha sido destructurar las relaciones en diferentes peticiones y aprovechar el poder y flexibilidad de, en este caso Laravel (aplicando repository pattern) + Inertia + Vue, para crear componentes que cargan y manejan los datos que necesitan a través de un store centralizado. Entre eso y los hooks de cada componente, el control en las cargas y el flujo de acciones contra la bd es un gusto.... tanto en efectividad como en mantenimiento y escalabilidad!

[@jordanalbano5191]

Admirable su capacidad de responder a los comentarios negativos. Muy buen aporte chicos

[@ivancordobadonet5432]

<a href="#" class="seekto" data-time="2475">41:15</a> Confirmo, nosotros en Opire justamente tenemos un event bus en memoria y fue un coste muy bajo (y a la larga nos ha aportado mucho mas valor) sobretodo cuando se introduce desde el principio. Es un poco engorro al principio tener que configurar todas las piezas cuando lo que quieres realmente es ponerte a hacer cosas de dominio pero nosotros lo vimos como una inversion a futuro

[@gabodeveloper_]

Excelente explicación! Solamente lo entenderán aquellos que hagan un query sobre millones de datos en cada tabla y cálculos sobre datos en sus campos y sean como 20 joins 😂 un gran abrazo a todo su equipo

[@cristiandavidippolito]

de acuerdo, una base de datos relacional BIEN normalizada y con buenos indices para un dominio, dificilmente se queda a nivel de performance... Por otro lado, creo que al patron de diseño que le apuntan cuando hablan de proyecciones es el CQRS

[@gposoft]

la fragmentación no siempre es la solución ya que existe casos de usos como polizas donde requieres ver toda la historia para poder hacer los calculos siempre lo que hace que fragmentacion de tabla no sirven en este caso si aplican proyecciones o vistas materializadas o tablas acumuladas ( proyecciones )

[@Bleibruk]

Estoy de acuerdo en que una razón de mayor peso es la independencia de equipos. Y es fundamental, porque, que cuesta más? La infra necesaria? O la perdida literal o potencial de clientes al no poder evolucionar el producto con la velocidad necesaria?😅 Ese collar no es para cualquier perro.

[@chechomancr4]

que hay de usar triggers en lugar del event bus?

[@juanmacolaneri4691]

Ojo que JOINT no es lo mismo que JOIN, en que pensabas Rafa?

[@tutorialesaleatorios]

Igual JOINT no existe en SQL

[@juanmacolaneri4691]

@@tutorialesaleatorios depende...