Hay un concepto interesante para bases de datos distribuidas, algunas (como PostgresSQL) permiten generar una federación. Permitiendo tener una replica de datos foráneos en el contexto de tu base de datos
no hay que elegir una forma, cada repository puede usa la que necesite. Por ejemplo puedes empezar por una vista (no materializada) y cambiar a proyección si el performance de lectura baja porque empieza a ser una query compleja
Las tablas foraneas, como por ejemplo en postgresql, para el caso de BD separadas, puede ser un caso interesante para proyecciones y vistas materializadas
Gracias por el video. Que beneficio hay en tener un Materliazed View Vs hacer otra tabla que se contenga el resultado de una Vista SGBD y que se actualice cada que se requiera?
En teoría "es lo mismo". El beneficio de la vista materializada radica en que es ofrecida por el propio SGBD. Esto implica optimizaciones internas y que no vas a tener que programar la sincronización de la tabla nueva. Con respecto de "y que se actualice cada que se requiera", ten cuidado. Recuerda que las vistas materializadas existen para esquivar la sobrecarga que existe al leer en las vistas tradicionales. Si creas una tabla y por cada insert, deleted o update en cualquiera de las tablas relacionadas en la vista tienes que actualizarla, estarás maximizando el impacto del golpe en el rendimiento. A mí en lo personal me gustan más las proyecciones. Es cierto que son "difíciles de mantener" pero me ayudan a mantener la lógica en la capa de aplicación.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Hay un concepto interesante para bases de datos distribuidas, algunas (como PostgresSQL) permiten generar una federación. Permitiendo tener una replica de datos foráneos en el contexto de tu base de datos
Este video fue todo aprendizaje para mí, muchas gracias por este contenido
Me Encanta!
Super Util y Super Divertido!
16:30 No he trabajado directamente con ello, pero juraría que tanto Oracle como otras BBDD sí permiten joins entre distintas BBDD.
Como molan estos 2
Ueueueue!! Gracias!!
no hay que elegir una forma, cada repository puede usa la que necesite. Por ejemplo puedes empezar por una vista (no materializada) y cambiar a proyección si el performance de lectura baja porque empieza a ser una query compleja
❤ que entretenido, gracias!!!
Las tablas foraneas, como por ejemplo en postgresql, para el caso de BD separadas, puede ser un caso interesante para proyecciones y vistas materializadas
Gracias por el video. Que beneficio hay en tener un Materliazed View Vs hacer otra tabla que se contenga el resultado de una Vista SGBD y que se actualice cada que se requiera?
En teoría "es lo mismo". El beneficio de la vista materializada radica en que es ofrecida por el propio SGBD. Esto implica optimizaciones internas y que no vas a tener que programar la sincronización de la tabla nueva.
Con respecto de "y que se actualice cada que se requiera", ten cuidado. Recuerda que las vistas materializadas existen para esquivar la sobrecarga que existe al leer en las vistas tradicionales. Si creas una tabla y por cada insert, deleted o update en cualquiera de las tablas relacionadas en la vista tienes que actualizarla, estarás maximizando el impacto del golpe en el rendimiento.
A mí en lo personal me gustan más las proyecciones. Es cierto que son "difíciles de mantener" pero me ayudan a mantener la lógica en la capa de aplicación.
Thanks!
Las vistas en el apartado de query sin joins debería estar en rojo, que no los veas no significa que no se ejecuten
y los codigo de descuento?
Quién ha dicho algo de códigos de descuento? 😅😂