‫Narrador: Uno de los pasos
‫más importantes en la creación de aplicaciones intensivas en datos
‫es modelar realmente todos estos datos en MongoDB.
‫Y de eso es de lo que vamos a hablar en esta conferencia.
‫Por lo tanto, es realmente crucial que
‫lo sigas, incluso al principio, es mucho para asimilar. Está bien.
‫De todos modos, comencemos ahora.
‫Ahora, el modelado de datos probablemente sea un concepto muy nuevo para usted.
‫Así que antes
‫de empezar; Dejemos en claro de qué vamos a hablar.
‫Entonces, el modelado de datos es el proceso de tomar datos
‫no estructurados generados por un escenario del mundo real y
‫luego estructurarlos en un modelo de datos lógicos en una
‫base de datos.
‫Y lo hacemos de acuerdo con un
‫conjunto de criterios que aprenderemos en este video.
‫Por ejemplo; digamos que queremos diseñar un modelo
‫de datos de tienda online.
‫Inicialmente habrá una tonelada de datos no estructurados que
‫sabemos que necesitamos.
‫Derecha.
‫Cosas como productos, categorías,
‫pedidos de clientes, carritos de compras, proveedores.
‫Y así sucesivamente y así sucesivamente.
‫Nuestro objetivo con el modelado de datos es luego estructurar
‫estos datos de una manera lógica.
‫Reflejando las relaciones del mundo real que
‫existen entre algunos de estos conjuntos de datos.
‫Un poco como puedes ver en este ejemplo.
‫Y esto, por supuesto, es solo una especie de situación imaginaria, pero
‫entiendes la idea.
‫Derecha.
‫Ahora, muchos desarrolladores de backend dicen que el modelado de datos
‫es donde más tenemos que pensar.
‫Esa es la parte más exigente de la construcción
‫de una aplicación completa.
‫Porque realmente no siempre es sencillo.
‫Y a veces simplemente no hay respuestas correctas.
‫Así que no es solo una forma única y correcta de estructurar los datos.
‫Pero de todos modos haré todo lo posible para establecer el
‫proceso en este video.
‫Y para eso vamos a seguir cuatro pasos.
‫Así que en el primer paso; aprendimos cómo identificar
‫diferentes tipos de relaciones entre datos.
‫Entonces
‫entenderemos la diferencia entre
‫referenciar o normalización e incrustación o desnormalización.
‫En el siguiente y
‫más importante paso; Le mostraré mi marco para
‫decidir si debemos incrustar documentos
‫o hacer referencia a otros documentos
‫en función de un par de factores diferentes.
‫Además, tenemos que hablar rápidamente sobre
‫diferentes tipos de referencias.
‫Porque eso es importante si ese es el tipo de
‫diseño que elegimos para nuestros datos.
‫Así que, de hecho, esta será una conferencia bastante teórica.
‫Pero también uno absolutamente esencial para su progreso
‫como desarrollador back-end.
‫Porque la forma en que diseñamos los datos y la forma en
‫que modelamos nuestros datos puede hacer o deshacer toda nuestra aplicación.
‫Y habrá muchos ejemplos a lo largo del camino
‫para facilitar este proceso.
‫Está bien.
‫Y lo primero de lo que
‫vamos a hablar es de los diferentes tipos
‫de relaciones que pueden existir entre los datos.
‫Entonces hay tres grandes tipos de relaciones.
‫Uno a uno, uno a muchos y muchos a muchos.
‫Y voy a usar una aplicación
‫de película como ejemplo en esta diapositiva.
‫¿Okey?
‫Entonces, primero, una relación uno a
‫uno entre datos es
‫básicamente cuando un campo solo puede tener un valor.
‫Entonces, en nuestro ejemplo de aplicación de película; una película solo
‫tiene un nombre.
‫Y este es un ejemplo
‫simple de una relación uno a uno.
‫Pero estas relaciones no son realmente tan importantes en
‫términos de modelado de datos.
‫Ahora, las relaciones más
‫importantes son las de muchas relaciones.
‫Y son tan importantes que en
‫MongoDB distinguimos entre tres tipos de relaciones
‫de uno a muchos.
‫Uno para unos pocos, uno para muchos, y uno para una tonelada o un
‫millón o algo así. Entonces, la diferencia aquí se
‫basa en la cantidad relativa de muchos. Está bien.
‫Entonces, un ejemplo de una relación de uno a
‫unos pocos es que una película puede ganar muchos premios, pero en realidad solo unos pocos.
‫Así que la película no va a ganar mil premios,
‫pero puede ganar algunos.
‫Y esta es una relación típica de uno a pocos.
‫Entonces, verá que, en general, una relación de uno
‫a muchos significa que un documento puede relacionarse con muchos otros documentos.
‫Ahora, esto puede parecer un poco abstracto sin los datos JSON, pero ese
‫es en realidad el propósito aquí.
‫Solo quiero mostrarles una descripción general
‫conceptual de estos diferentes tipos de relaciones.
‫De todos modos, cualquier relación de uno a
‫muchos, un documento puede relacionarse con cientos o miles
‫de otros documentos.
‫Por ejemplo; una película puede tener miles de
‫reseñas en nuestra aplicación.
‫Y entonces esta no es realmente una relación de uno a pocos, sino
‫de uno a muchos. ¿Okey?
‫Y finalmente tenemos la relación one to ton.
‫Imagínese que quisiéramos implementar alguna funcionalidad de registro
‫en nuestra aplicación. Básicamente, para saber exactamente
‫qué está pasando en nuestro servidor.
‫Estos registros pueden crecer fácilmente a millones de documentos.
‫Y este es un ejemplo muy
‫típico de una relación de uno a toneladas.
‫Y la diferencia entre muchos y una tonelada es,
‫por supuesto, un poco confusa, pero piense que si algo puede
‫crecer casi hasta el infinito, definitivamente es una
‫relación de uno a una tonelada.
‫Así que, de nuevo, las relaciones de uno a
‫muchos son las más importantes que debe conocer.
‫Por cierto; en las bases
‫de datos relacionales hay solo uno a
‫muchos sin cuantificar cuánto es realmente.
‫En las bases de datos de
‫MongoDB, sin embargo, es una diferencia extremadamente importante.
‫Porque es uno de los factores que usaremos
‫para decidir si debemos desnormalizar o
‫normalizar los datos, como aprenderá un poco más adelante.
‫De todos modos, el tipo de relación menor es el de muchos
‫a muchos donde una película puede tener muchos actores.
‫Pero al mismo tiempo, un actor puede actuar en muchas películas.
‫Y aquí la relación básicamente va
‫en ambas direcciones.
‫Donde antes en los otros tipos
‫era solo en una dirección.
‫Por ejemplo, una película puede tener muchas reseñas, pero una
‫específica es solo para esa película. Derecha.
‫Y lo mismo ocurre con los premios.
‫Entonces, un premio específico como el mejor
‫actor es para una sola película, no para varias.
‫Pero con las películas y los actores es realmente diferente.
‫Una vez más, una película está protagonizada por muchos actores, pero
‫un actor interpreta muchas películas, por
‫lo que es una relación de muchos a muchos.
‫Bueno.
‫Así que tenga todo esto en cuenta a medida que avanzamos
‫en esta conferencia.
‫Y probablemente el aspecto más importante que necesitamos aprender sobre
‫las bases de datos de MongoDB es hacer referencia
‫e incrustar dos conjuntos de datos.
‫Y en realidad ya hablamos
‫un poco sobre esto antes, pero revisémoslo aquí
‫y profundicemos un poco más también.
‫Entonces, cada vez que tengamos dos
‫conjuntos de datos relacionados, podemos representar esos datos relacionados en
‫una forma de referencia o normalizada o en una forma incrustada o desnormalizada.
‫Y sigo usando los dos términos relacionados juntos, como hacer
‫referencia y normalizar, porque verá que
‫ambos se usan y, por
‫lo tanto, es importante que los conozca todos.
‫De todos modos, en el formulario referenciado mantenemos dos conjuntos de
‫datos relacionados y todos los documentos separados.
‫Entonces, nuevamente, todos los datos están bien separados,
‫que es exactamente lo que significa normalizado.
‫Continuando, el ejemplo de la base de datos de películas de
‫antes tendríamos un documento de película y un documento
‫de actor para cada actor. Ahora, ¿cómo haríamos la conexión
‫entre la película y los actores para que luego en nuestra aplicación
‫podamos mostrar qué actores interpretaron en una película en particular?
‫Porque si todos son documentos completamente diferentes, la película no tiene
‫forma de conocer a los actores. Derecha.
‫Bueno, ahí es donde entran las identificaciones.
‫Entonces usamos los ID de actor para crear referencias en el
‫documento de la película.
‫Conectando películas con actores de manera efectiva.
‫Entonces ves que en un documento de película tenemos una matriz
‫donde almacenamos las identificaciones de todos los
‫actores para que cuando solicitemos datos sobre cierta película podamos
‫identificar fácilmente a sus actores. ¿Tiene sentido?
‫Ahora bien, este tipo de referencia se llama referencia secundaria porque es el
‫padre en este caso la película que hace
‫referencia a sus hijos. En este caso los actores.
‫Entonces realmente estamos creando una especie de jerarquía aquí. Derecha.
‫Ahora también hay referencias de padres y hablaremos
‫de eso un poco más tarde.
‫Y por cierto en bases de datos relacionales; todos los datos siempre
‫se representan en forma normalizada de esta manera.
‫Pero en una base de datos sin secuelas
‫como MongoDB, podemos desnormalizar los datos en una forma
‫desnormalizada simplemente incrustando el documento
‫relacionado directamente en el documento principal.
‫Así que ahora tenemos todos los datos
‫relevantes sobre los actores dentro de un documento de película principal
‫sin la necesidad de documentos, colecciones e identificaciones por separado.
‫Entonces, nuevamente, si elegimos desnormalizar o incrustar nuestros datos, tendremos un
‫documento principal que contiene todos los datos principales, así como
‫los datos relacionados. Está bien.
‫Y el resultado de esto es que nuestra aplicación
‫necesitará menos consultas a la base de datos.
‫Porque podemos obtener
‫todos los datos sobre películas y actores al
‫mismo tiempo, lo que, por supuesto, aumentará nuestro rendimiento.
‫Ahora, la desventaja aquí es, por
‫supuesto, que realmente no podemos consultar los datos incrustados por sí solos.
‫Entonces, si ese es un requisito para la aplicación,
‫tendría que elegir un diseño normalizado y, dado
‫que estamos hablando de los pros y
‫los contras de la forma desnormalizada; hagamos lo
‫mismo con el diseño normalizado.
‫Y básicamente es todo lo contrario de
‫lo que acabamos de hablar.
‫Por lo tanto, hay una mejora en
‫el rendimiento cuando a menudo necesitamos consultar los datos relacionados por sí
‫mismos porque luego podemos consultar los datos que necesitamos y
‫no siempre las películas y los actores juntos.
‫Pero en la otra mano; cuando realmente necesitemos consultar
‫películas y actores juntos, entonces necesitaremos
‫muchas consultas a la base de datos.
‫Entonces, primero la consulta para la película y luego a partir de
‫ahí también necesitaremos una consulta para el actor y
‫eso, por supuesto, funciona para el rendimiento.
‫Entonces, al diseñar su base de datos; este es el tipo de cosas que
‫debe tener en cuenta. Está bien.
‫Y ahora solo como nota al margen; Por supuesto, podríamos comenzar nuestro proceso
‫de pensamiento con datos desnormalizados y
‫luego llegar a la conclusión de que es
‫mejor normalizar los datos.
‫Entonces, cuando pensamos en nuestro modelo de datos, esta forma de
‫organizar los datos funciona, por supuesto, en ambos sentidos.
‫Ahora bien, ¿cómo decidimos realmente si debemos normalizar
‫o desnormalizar los datos?
‫Bueno, eso es exactamente lo que aprenderemos a continuación.
‫Entonces, cuando tenemos dos conjuntos de datos relacionados; tenemos que decidir
‫si vamos a incrustar los conjuntos de datos o si
‫los mantendremos separados y
‫referenciarlos de un conjunto de datos a otro.
‫Y como que desarrollé este marco
‫de decisión, les mostraré dónde usamos tres criterios para
‫tomar esa decisión.
‫Primero, analizamos el tipo de relaciones que
‫existen entre los conjuntos de datos.
‫En segundo lugar, intentamos determinar el patrón de acceso
‫a los datos del conjunto de datos que queremos incrustar o hacer referencia.
‫Y esto solo significa analizar la frecuencia con la que se leen y
‫escriben los datos en ese conjunto de datos.
‫Luego también miramos algo que yo llamo cercanía de datos.
‫Y la cercanía de datos es un término que acabo de inventar,
‫pero lo que significa es cuánto están realmente relacionados los datos y cómo
‫queremos consultar los datos de la base de datos.
‫Y esto tendrá más sentido
‫cuando hablemos de ello en un momento.
‫Ahora para tomar realmente la decisión; Necesitamos combinar todos estos
‫tres criterios y no usar
‫solo uno de ellos de forma aislada.
‫Así por ejemplo; El hecho de que el criterio número
‫uno diga incrustar no significa que no necesitemos
‫mirar los otros dos criterios.
‫Muy bien y comencemos con el tipo de relación.
‫Entonces, por lo general, cuando tenemos una relación de uno a pocos,
‫siempre incorporamos el conjunto de datos relacionado en el
‫conjunto de datos principal, tal como aprendimos en
‫la última diapositiva. Derecha.
‫Ahora en una relación de uno a muchos; las cosas son
‫un poco más borrosas, por lo que está bien incrustar o hacer referencia.
‫En ese caso tendremos que decidir
‫según los otros dos criterios.
‫Ahora, por otro lado, en una relación
‫de uno a una tonelada o de muchos a muchos, generalmente siempre hacemos
‫referencia a los datos. Eso es porque si realmente
‫hiciéramos incrustaciones en este caso, podríamos crear rápidamente un documento demasiado grande.
‫Incluso superando potencialmente el máximo de 16 megabytes.
‫Entonces, la solución para eso es, por supuesto, hacer referencia
‫a los datos o normalizarlos. Y como un ejemplo rápido;
‫digamos que en nuestro ejemplo de base
‫de datos de películas tenemos alrededor de 100 imágenes asociadas a cada película.
‫Entonces, podríamos decir que es una relación de uno a
‫muchos, pero ¿vamos a incrustar el conjunto de datos o deberíamos
‫hacer referencia a ellos aquí? Bueno, realmente no lo sabemos.
‫Así que echemos un vistazo a los otros dos criterios.
‫Entonces, el segundo trata sobre los patrones de acceso a datos,
‫donde es solo una
‫descripción elegante para evaluar si un
‫determinado conjunto de datos se escribe o se lee principalmente.
‫Entonces, si el conjunto de datos sobre el que estamos decidiendo se
‫lee principalmente y los datos no
‫se actualizan mucho, probablemente deberíamos incrustar ese conjunto de datos.
‫Entonces, una alta proporción de lectura / escritura solo significa
‫que hay mucha más lectura que escritura.
‫Y una vez más, un conjunto de datos como ese es un buen candidato
‫para la incrustación.
‫La razón de esto es que al incrustar solo necesitamos un
‫viaje a la base de datos por consulta.
‫Mientras que para hacer referencia necesitamos dos viajes. Derecha.
‫Entonces, si incrustamos datos que se leen mucho; en cada consulta,
‫guardamos un viaje a la base de
‫datos, lo que hace que todo el proceso sea mucho más eficiente.
‫Así que creo que nuestro ejemplo de imagen de
‫película sería un buen candidato para incrustar.
‫Porque una vez que las 100 imágenes se guardan en
‫la base de datos, ya no se
‫actualizan realmente porque realmente no hay nada que actualizar
‫sobre una imagen. Bien, todo se
‫trata de leer y, por lo tanto,
‫según este criterio, incrustaríamos los documentos con imágenes.
‫Ahora, por otro lado, si nuestros datos se
‫actualizan mucho, entonces deberíamos considerar hacer referencia o normalizar los datos.
‫Eso es porque es más trabajo para el motor de base
‫de datos actualizar e incrustar
‫un documento que un documento independiente más simple.
‫Y dado que nuestro principal objetivo es el rendimiento;
‫simplemente normalizamos el conjunto de datos.
‫En nuestro ejemplo, digamos que cada película tiene muchas reseñas
‫y el usuario puede marcar cada reseña como útil.
‫Así que cada vez que alguien hace clic en esta revisión fue útil
‫en nuestra aplicación. Necesitamos
‫actualizar el documento correspondiente.
‫Y esto significa que los datos pueden cambiar todo el
‫tiempo, por lo que este es un gran candidato para la normalización.
‫Nuevamente, porque no queremos consultar las películas todo
‫el tiempo si todo lo que realmente queremos actualizar son
‫las reseñas marcándolas como útiles.
‫Vale, ¿eso tiene sentido?
‫Y finalmente al último criterio lo llamo cercanía de datos; que
‫es como una medida de cuánto están
‫relacionados los datos. Entonces, si los
‫dos conjuntos de datos realmente pertenecen juntos de manera
‫intrínseca, probablemente deberían estar integrados entre sí.
‫En nuestro ejemplo; Todos los usuarios pueden tener muchas direcciones de correo electrónico
‫en su cuenta y, dado que están tan intrínsecamente
‫conectados al usuario, no hay duda de que los correos
‫electrónicos deben estar integrados en el documento.
‫Ahora bien, si con frecuencia necesitamos consultar ambos conjuntos de datos por sí
‫mismos, entonces esa es una muy buena
‫razón para normalizar los datos en dos conjuntos de datos separados.
‫Incluso si están estrechamente relacionados.
‫Así que imagina que en nuestra aplicación
‫tenemos un cuestionario en el que los usuarios tienen que identificar una película basada en imágenes.
‫Esto significa que vamos a consultar muchas imágenes
‫por su cuenta.
‫Así que sin tener que consultar necesariamente las películas en sí.
‫Y así si aplicamos este tercer criterio; llegamos a
‫la conclusión de que en realidad deberíamos normalizar el conjunto de
‫datos de imágenes. Está bien.
‫Porque de nuevo si implementamos esta funcionalidad de cuestionario; las
‫imágenes se consultarán solas todo el tiempo.
‫Entonces, todo esto muestra que realmente deberíamos mirar los
‫tres criterios juntos en lugar
‫de solo uno de ellos de forma aislada.
‫Porque eso podría llevar a decisiones menos óptimas.
‫Y digo menos óptimas en lugar de incorrectas
‫porque en realidad no son formas
‫completamente correctas o completamente incorrectas de modelar nuestros datos.
‫No hay reglas estrictas; estas son solo pautas que puede
‫seguir para encontrar la forma
‫probablemente más correcta de estructurar sus datos.
‫Pero, de nuevo, es difícil estar realmente equivocado.
‫¿Okey?
‫Ahora, digamos que hemos optado por normalizar nuestros conjuntos
‫de datos.
‫En otras palabras, hacer referencia a los datos.
‫Luego, después de eso, todavía tenemos
‫que elegir entre tres tipos diferentes de referencias.
‫Referencias de niños, referencias de padres
‫y referencias bidireccionales.
‫Entonces, el primer tipo es la referencia a niños.
‫Cuál es el tipo de referencia que te mostré antes.
‫¿Okey?
‫Y no tomemos el ejemplo de registro de errores
‫que mencioné anteriormente. Donde potencialmente
‫podríamos tener millones de documentos bloqueados.
‫Así que en referencia infantil; Básicamente, mantenemos referencias a los
‫documentos secundarios relacionados en un documento principal.
‫Y generalmente se almacenan en una matriz.
‫Entonces ve que cada registro tiene una ID y
‫luego en el documento de la aplicación hay esa matriz con
‫todas estas ID. ¿Derecha?
‫Sin embargo, el problema aquí es que
‫esta matriz de ID puede volverse muy grande si hay muchos niños.
‫Y este es un anti-patrón en MongoDB.
‫Entonces, algo que debemos evitar a toda costa.
‫Además, la referencia de niños hace
‫que los padres y los niños estén muy unidos.
‫Lo que no siempre es lo ideal. Pero esa es exactamente la
‫razón por la que tenemos referencias de padres.
‫Entonces, en referencia a los padres; en realidad
‫funciona al revés.
‫Así que aquí, en cada documento secundario, mantenemos una
‫referencia al elemento principal.
‫Por lo tanto, el nombre de referencia de los padres.
‫En este ejemplo, el ID de la aplicación es 23, por
‫lo que en cada registro está el campo de
‫la aplicación con el ID 23.
‫Para que el niño siempre conozca a su padre.
‫Entonces, en este caso, el padre no sabe nada
‫sobre los hijos.
‫No quiénes son ni cuántos son.
‫Por lo tanto, están mucho más aislados e independientes.
‫En eso, a veces puede ser beneficioso.
‫Entonces, ¿cuál de estos dos tipos es realmente mejor para
‫esta relación de datos?
‫Y recuerde cómo dije que podría haber
‫millones de registros, por lo que supongamos que hay
‫dos millones de documentos registrados.
‫En el caso de referencias de niños, eso significaría que hay dos
‫millones de referencias de ID
‫en el documento de la aplicación.
‫¿Derecha? Ahora también recuerde cómo dije
‫que hay un límite de 16 megabytes en documentos.
‫Entonces, si seguimos agregando y agregando estas ID de niños en
‫la matriz en el padre; entonces
‫alcanzaríamos rápidamente ese límite de 16 megabytes que
‫puede contener cada documento Bson.
‫Simplemente porque esa matriz crecerá mucho.
‫Así que eso no va a funcionar realmente.
‫¿Lo es?
‫Por otro lado, con los padres
‫haciendo referencia a ese problema no sucederá.
‫Simplemente tendremos dos millones de documentos
‫bloqueados como antes, pero cada uno de ellos tiene la identificación de su padre.
‫Pero no hay una matriz que
‫crezca indefinidamente y, por lo tanto, la referencia
‫a los padres sería la mejor solución aquí.
‫Entonces, la conclusión de todo esto es que,
‫en general, la referencia infantil se usa mejor
‫para una o varias relaciones. Donde sabemos de antemano
‫que la variedad de documentos secundarios no crecerá tanto.
‫Por otro lado, la referencia a los padres se usa
‫mejor para relaciones de uno a muchos y de uno a una
‫tonelada como esta. ¿Okey?
‫Entonces, nuevamente, tenga siempre en cuenta que uno de los principios
‫más importantes del modelado de datos de MongoDB
‫es que nunca se debe permitir que la matriz crezca indefinidamente.
‫Para nunca romper ese límite de 16 megabytes.
‫Tampoco queremos enviar a nuestros usuarios una matriz con
‫miles de ID cada vez que soliciten un
‫conjunto de datos principal. ¿Okey?
‫Entonces, ¿esta lógica tiene sentido para ti?
‫Luego pasemos al tercer tipo de referencia
‫que es referencia bidireccional.
‫Y esta vez con el ejemplo de la película y
‫el actor que les mostré cuando hablamos
‫de muchas a muchas relaciones. ¿Recuérdalo?
‫Entonces, nuevamente, cada película tiene muchos actores y
‫cada actor juega en muchas películas.
‫Y esa es una relación típica de muchos a muchos.
‫Y usualmente usamos esta referencia bidireccional para diseñar relaciones
‫de muchos a muchos. Y funciona
‫así; En cada película guardaremos referencias a todos los
‫actores que protagonizan esa película. Así que un poco como en las referencias de niños.
‫Sin embargo y al mismo tiempo en cada actor
‫también guardamos referencias a todas las películas en
‫las que actuó el actor.
‫Entonces, las películas y los actores están conectados en ambas direcciones.
‫Por lo tanto, el nombre de referencia bidireccional.
‫Y esto hace que sea
‫realmente fácil buscar películas y actores de forma completamente independiente.
‫Al mismo tiempo que facilita la búsqueda de
‫los actores asociados a cada película y las películas asociadas
‫a cada actor.
‫(respiración profunda)
‫Esta fue una conferencia bastante larga.
‫Con muchos conceptos nuevos, principios y
‫pautas para recordar.
‫Así que para poder ayudarte con eso; Aquí va un
‫resumen rápido y algunas pautas más generales que puede
‫consultar cuando lo necesite.
‫Entonces, el principio más importante es: estructurar sus datos para que
‫coincidan con las formas en que su aplicación consulta y
‫actualiza los datos.
‫O en otras palabras: identifique primero las preguntas que surjan de los casos
‫de uso de su aplicación y luego
‫modele sus datos para que las preguntas puedan ser
‫respondidas de la manera más eficiente.
‫Por ejemplo; cuando necesito consultar películas y actores siempre
‫juntos o hay escenarios en los que solo consulto
‫películas o solo actores.
‫Ese tipo de preguntas es en qué
‫se basará su modelo de datos.
‫En general, siempre favorezca la incrustación a menos que haya una buena
‫razón para no hacerlo.
‫Especialmente en relaciones de una a pocas y de una a muchas.
‫A continuación, una relación de uno a una tonelada o de muchos a muchos
‫suele ser una buena razón para hacer referencia en lugar de incrustar.
‫Además, favorezca las referencias cuando los datos se actualizan mucho
‫y si necesita acceder con frecuencia a un conjunto de datos por sí solo.
‫Utilice la incrustación cuando la mayoría de los datos se leen pero rara vez se
‫actualizan y cuando dos conjuntos de datos pertenecen intrínsecamente juntos.
‫No permita que las matrices crezcan indefinidamente.
‫Por lo tanto, si desea normalizar; use referencias de
‫niños para relaciones de una a muchas y referencias de padres para
‫relaciones de una a una tonelada.
‫Y finalmente use referencias bidireccionales
‫para muchas relaciones.
‫¿Está bien?
‫Y eso lo resume bastante bien.
‫De hecho, te recomendaría que veas este video
‫dos veces si puedes, solo por lo importante que
‫es este material. ¿Está bien?
‫De todos modos, nos vemos en el siguiente video.