Colecciones vs subcolecciones

Un top level collection se utilizaria para relaciones de tipo “agregacion”. Mientras que una sub collection se utilizaria para relaciones tipo “composicion”.

Por ejemplo:

Tenemos Estudiantes, Cursos y Notas. Los estudiantes tiene cursos y los cursos tiene estudiantes. Si se elimina un curso los estudiantes no deben ser eliminados. Lo mismo si se elimina un estudiante los cursos no deben ser elimiandos. Esto es una relacion de agregacion. Aqui se usaria top level collection para estudiantes y cursos.

Los estudiantes tienen notas y las notas pertenecen a un estudiante. Si se elimina un estudiante, tiene sentido eliminar las notas. Esto es una relacion de composicion. Aqui se usarian las subcollections. El estudiante tendría una subcollection de notas.

En esta clase de mongo db hablan mas a fondo sobre documentos embebidos y como relacionar los documentos entre si documentos embebidos por cierto deberian de seguir con el curso de mongodb despues de haber curso este curso sobre fundamentos

Un ejemplo que me sirvió para entender es:

• Una persona que tiene acceso a un gimnasio es una colección
• Cada persona diferente es un documento.
• Esa persona tiene familiares que acceden al gimnasio por ser familiares.
  Entonces esos familiares están ligados a la persona que pagó, por lo tanto son subcolecciones, si esa persona deja de pagar las demás personas no pueden ingresar al gimnasio.

Podemos imaginar los documentos como objetos en programación, supongo que una subcolección sería como una variable de ese mismo objeto, a la cual solo ese puede acceder y depende de él para existir.

Notas:
El uso de sub-colecciones es mas recomendado para cuando requieres de acceder a esa información o esos documentos cuando accedes al documento padre y no requieres de referenciar desde otro documento padre

Cuando se requiere de listar de forma independiente esa colección es mejor usar de colección de Top Level y hacer reference dentro de los documentos que la requieren

Aquí se dice algo muy importante y que es muy cierto, el usar top level colection o subcolection depente de las buenas prácticas y las necesidades, algo que se menciona en el curso de Firebase para la Web por Bedu es que tratemos de tener la menor cantidad de subcolecciones posibles, y si muchas colecciones van a tener subcolecciones smilares, lo mejor es hacer una top level collection y relacionarla por medio de un identificador con otras clecciones ^^

Subcolecciones
Son colecciones asignadas a un documento y sólo se pueden acceder a ellas accediendo al documento
Colecciones y subcolecciones
La asignación de colecciones y subcolecciones dependen de lo que queramos conseguir. Si la colección va a ser una entidad separada (relación de agregación con otros documentos) a la que vamos a consultar desde distintos lugares conviene crear una top level collection.
Si la relación esta subordinada al documento (relación de composición), conviene usar una subcolección
Una forma fácil de determinar el uso de colecciones o subcolecciones es verificar si tiene sentido que si eliminamos el documento también se elimine la posible subcolección no

Nota
Firestore es más flexible con respecto a la estructura de datos; pueden existir entradas que no necesariamente obedezcan a la estructura planteada inicialmente

Entendido, entonces la diferencia principal entre las subcolecciones y las colecciones, es que las primeras son usadas generalmente para la creación de documentos de una entidad que solo interactúa con otra como es el caso de las etiquetas que solo se utilizan en los posts, en cambio las colecciones van a estar destinadas para los documentos de entidades que van a interaccionar con más de una entidad. De esta forma ya se establece una agrupación para que la subcolección se relacione directamente con un tipo de colección.

Esto podria ayudarnos a entender un poco mas el concepto de colecciones

Collection: users	
	Document: alovelace
		Data:
		first : "Ada"
		last : "Lovelace"
		born : 1815

		Document: aturing
		Data
		first : "Alan"
		last : "Turing"
   born : 1912

Tal vez se empiezan a presentar confusiones porque en mi caso estaba acostumbrado a manejar solo bases de datos relacionales en las que uno ya tiene el concepto de llaves primarias y llaves foráneas para relacionar tablas, pero bueno como en cada clase vista Israel sabe explicar muy bien cada concepto para poder tener claro el manejo de este tipo de bases de datos y su buen uso.

¿Entre usar una colección que guarde etiquetas con nombre y usar un array que guarde los nombres?
¿Qué es más recomendado?

Según la documentación: Si borras un documento, no se borrarán las subcolecciones que contiene.

Cuando borras un documento que tiene subcolecciones, estas no se borran. Por ejemplo, puede haber un documento ubicado en coll/doc/subcoll/subdoc, aunque el documento coll/doc ya no exista. Si deseas borrar los documentos de las subcolecciones cuando borras un documento principal, debes hacerlo de forma manual, como se muestra en la sección Borra colecciones.

A fecha de 13-01-22, se actualizaron los nombres en la aplicación firebase asi:

• añadir coleccion–>iniciar coleccion
• añadir documento–>agregar documento
• añadir campo–>agregar campo
  
  

La experiencia manejando y creando bases de datos son las que nos van a dar la habilidad para crearla de manera ordenada y coherente.

Para desarrollar ese buen criterio definitivamente se necesitan horas de cancha

Creo que me siento más atraída por las bases de datos no relacionales

Si tienes una entidad separada que vas a referenciar desde muchos lugares es recomendado usar un top level collection. Por el otro lado si se necesita hacer algo intrínseco al documento es aconsejable usar subcolecciones.

Me esta dando miedo como va a venir este examen jaja se aventó todos los videos de corrido sin exámenes intermedios :'v

Entonces poniendo como ejemplo los comentarios, estos deberían ir en una subcoleccion ya que solo se deben ver cuando se entra a los posts? o alguien me podría proporcionar un ejemplo mas claro.

SUpongo que para una empresa puede ser muy útil combinar las bases de datos relaciones con las no relacionales, ya que ambas son poderosas a su manera en particular

Sorprendente como funcionan estas nuevas bases de datos, no se si se tratará más adelante pero sería interesantísimo saber como se hacen consultas?

Las subcolecciones

• Asi se ven las subcolecciones en python

 
sakdjfiefjiejfi = { 

		"Nombre": "Laura", 
                   
    "Apellido":"Martinez",
                    
    "etiquetas":{"nombre":"ciencia", 
                                
                 "nombre_etiqueta":"Ciencia"} 

									
 }

¿En que ámbitos laborales se hace uso de My SQL y en cuales Firestone?

Para mi una sub colección vendría siendo una colección relacional a una colección madre (hay relación)

Para base de datos documental, MongoDB implementa:

• La forma más natural y productiva de trabajar con datos.
  Admite matrices y objetos anidados como valores.

+Lenguaje de consulta rico y expresivo que permite filtrar y ordenar por cualquier campo, independientemente de cómo esté incrustado en un documento.

+Admite agregaciones y otros casos de uso modernos, como búsqueda de gráficos o texto, y búsqueda basada en información geoespacial.

+Las propias consultas son también JSON, por lo que se programan fácilmente. Olvídese de concatenar cadenas para generar consultas SQL de forma dinámica.

Colecciones vs Subcolecciones

Consejos casos de uso

• Top level collections: Entidad separada referenciada desde muchos lugares o muy consultada.
• Subcolecciones: Consultas intrínsecas al documento

De verdad que es bien intuitivo, quedo con la curiosidad de saber más, sobre todo a la hora de implementarlo desde en un Backend, ya que desde la versión web solo es para aprender como manejarlo pero la aplicación es muy poca.

me surgió una duda, entonces si quieres guardar información en tu base a través de un formulario desde tu página, debes de guardar los registros de la misma manera a como estan en el json?

Se habla de que, entre un motor sql y uno nosql, hay que pensar el caso de uso para elegir uno u otro, pero puede pasar perfectamente que una vez que yo elegí, por ejemplo nosql para un caso de uso de mi sistema, y unas tablas quedaron con ese motor.

Pero después con la evolución del sistema, resulta que se requiere hacer muchas consultas con unión de tablas para hacer reportes completos, y pero se están combinando tablas en un motor sql con otro nosql. Por lo que la cosa cambió totalmente y se comenzó a complicar.

Qué hacer en esos casos? creo que es mucho más difícil que la manera simplista que se explica en las clases

Alguien pudo ver si se puede importar base de datos a Firebase?

No veo la aplicación práctica de este tipo de bases de datos. Se supone que una base de datos siempre debería tener una estructura determinada y relaciones en las mismas. No se si estoy perdido, pero alguien me podria explicar por favor un caso de negocio donde esté tipo de base de datos es la idonea?

• Si es entidad separada, que se va referenciar desde muchos lugares o se van a realizar muchas consultas hacia ella, escoger TLC. Si se quiere algo intrínseco al documento y que no se deba traer toda la información de inicio sino hasta que se entra al documento (beneficios: más rápido en red, menor consumo de datos, menor consumo de almacenamiento de DB), escoger Sub-colletion

Apuntes:
Una subcoleccion difiere totalmente de un top level collection, en cuestión de que se crearía una colección dentro de un documento en cuestión, por lo que se crearía una colección aparte de ese documento en específico.

Es cierto que las bbdd nosql son mas flexibles, pero como persona que le gusta el orden, creo que prefiero las bbdd sql para estructurar el groso del proyecto, aunque si es cierto que a veces esta bien usar una bbdd nosql para cosas concretas. Que opinais los que teneis mas experiencia?

Me gusta mucho esta base de datos, porque se ve mas amigable, ademas que me recuerda a un diccionario en programacion. 😄

Buena analogia con el proyecto de platzi blog entre MySql y Firebase

Excelente clase, Israel. 😄

Excelente clase a seguir practicando

interesante!

La particularidad de las top level collections es que existen en el primer nivel de manera intrínseca. Las subcolecciones ya no vivirán al inicio de la base de datos.

Desconocía las subcolecciones

Arbolitos… 😜

En el mundo real, la etiqueta ciencia y espectáculos no son tan incompatibles, ya que hay actrices famosas que han aportado mucho a la ciencia 😉

Diferencia de SQL y NoSQL: Las bases de datos de SQL son mas estrictas con su estructura de forma que te piden normalizar todas las entidades que generas para luego hacer las relaciones entre asi y posteriormente almacenar los datos lo que hace que sea algo un poco mas complicado al momento de cambiar los datos o ese tipo de cosas, es decir que necesitas pensar muy bien en las entidades y su definicion dentro del proyecto.
|
Por otro lado las NoSQL que se basan en documentos, son mucho mas flexibles a este aspecto, puedo crear un blogspot que tenga una fecha de publicacion y enseguida crear otra que nisiquiera la tenga o que tenga otros elementos diferentes y en este caso es donde se hace la diferencia por que comparandolo con SQL tienen que tener todas las estructuras de la forma en cambio NoSQL tiene flexibilidad y la DB no te dira que es inconsistente o generara algun tipo de error

Me parece increíble Firestore. Una interfaz limpia, moderna e intuitiva!

Las bases de datos basadas en documentos son mucho más flexibles al respecto, nosotros podemos poner un blogpost con una noticia que tenga fecha de recuperación. Sin embargo, también se puede crear otros que no las tengan. La base de datos no nos dice no es inconsistente o que no está normalizada, nos permite perfectamente crear.

Las Top level collections son para cuando son cosas muy generales, como en este caso los posts o los usuarios y las collections anidadas son para cosas que van a estar solo dentro de otras cosas. Por ejemplo, si un post tiene ciertas imágenes, podríamos guardar las imágenes en una sub colección, ya que no vamos a tener la necesidad de buscar

Hola :
Al agregar un documento al terminar de asignar los campos, al profesor se le despliega en automático la opción de guardar y si no nombra un ID, Cloud Firestore le asigna un ID autómatico de manera natural y puedes guardar el documento.

En la versión 2021 de Cloud Firestore en el procedimiento anterior, si no nombramos el ID , hay que darle "Cick"
en la opción ID automático para que se genere y nos permita guardar el documento.

¡Saludos!

Atte.

Aníbal

regla para determinar Top Level vs. Sub collections

Aún no sé si la lógica es correcta pero es para empezar a familiarizarse

Buena clase.
Hay que tener en cuenta la subcoleccion, esto nos ayuda a mejorar el rendimiento, pero hay que ser muy organizado.

Excelente interfaz la de Firestore.

increible video fue el mejor

genial

Las bases de datos de grafos resuelven bastante bien el dilema de las colecciones y subcolecciones.

Muy buena la platadorma firestore, bastante didactica. quisiera saber si se puede usar la opcion reingeniering como en workbench?

A mi no me sale esa plataforma tan visual en firestore ¿alguien sabe donde puedo habilitarla?

El uso de sub-colecciones es mas recomendado para cuando requieres de acceder a esa información o esos documentos cuando accedes al documento padre y no requieres de referenciar desde otro documento padre

Excelente clase.

Las colecciones que se agregan en la tercera columna son intrínsecas al documentos original

No es bueno debido a que no podemos consultar relaciones entre tablas si no tienen los datos

Lo de las subcolecciones me parece que podría ser como tipo padre hijo, maestro detalle

Me gustó lo flexible que es Firestore

Gracias

¿En este tipo de base de datos como se crean relaciones entre documentos?

Debe ser por falta de costumbre de utilizar este producto, pero me cuesta un poco comprender.
En todo caso, volveré a ver el video.

Sub colección hace referencia a una entidad dependiente (BD Relacional)

Gracias!

Según la documentación: Los documentos de las subcolecciones también pueden contener subcolecciones, lo que te permite anidar datos en más niveles. Puedes anidar datos hasta 100 niveles de profundidad.

las entidades pasan a ser documentos? y los atributos pasarían a ser colecciones?

A poner en práctica las colecciones y las subcolecciones con el proyecto en paralelo que estoy realizando sobre el cine.

Definitivamente es un desperdicio ver la sola clase sin echarle un buen y largo vistazo a los aportes y preguntas. Se generan tantas inquietudes y se solucionan muchas otras 😃 .

y cuál es la diferencia o cual sería lo mas recomendable tomando en cuenta las características de una subcolección, campo tipo map o subcolección?

Tengo la duda de si pudo haber solucionado esa petición, en lugar de hacer una subcolección, poniendo un array tipo etiquetas

Me gusta lo flexible que es Firestore

las subcollections, la forma en que lo veo, es con el ejemplo de un expediente judicial. Solo voy a traer datos especificos cuando consulte un expediente particular que son únicos. No voy a consultar datos de otros expedientes.

Supongamos que estás construyendo una aplicación de redes sociales. Puedes tener una colección "usuarios" que almacene documentos de usuarios. Cada documento de usuario puede contener una subcolección "publicaciones" que almacena las publicaciones del usuario. Dentro de la subcolección "publicaciones", cada documento puede contener campos como "título", "contenido" y "fecha".

Colecciones:

Una colección es un grupo de documentos dentro de una base de datos Firestore.
Los documentos en una colección no tienen que tener una estructura de datos consistente; cada documento puede tener sus propios campos y valores.
Puedes realizar consultas en una colección para recuperar documentos que cumplan con ciertos criterios.
Firestore admite un nivel superior de anidamiento de colecciones (subcolecciones), pero no puedes tener colecciones anidadas de forma infinita.
Las colecciones se utilizan comúnmente para agrupar documentos relacionados. Por ejemplo, podrías tener una colección “usuarios” que almacene documentos de usuarios y otra colección “publicaciones” que almacene documentos de publicaciones.
Subcolecciones:

• Una subcolección es una colección anidada dentro de un documento específico en Firestore.
  Las subcolecciones son útiles cuando deseas relacionar documentos dentro de una jerarquía específica. Por ejemplo, puedes tener un documento de usuario en la colección “usuarios” y una subcolección “publicaciones” dentro de ese documento para almacenar todas las publicaciones relacionadas con ese usuario.
  Las subcolecciones pueden anidarse a varios niveles de profundidad dentro de documentos, pero debes tener en cuenta que Firestore cobra por cada lectura y escritura en colecciones y subcolecciones.
  Las subcolecciones pueden contener sus propios documentos y subcolecciones, lo que permite una estructura jerárquica más compleja.

Usa Colecciones cuando:

Los documentos están relacionados pero no necesitas una estructura jerárquica compleja: Si los documentos que estás almacenando no tienen datos anidados significativos y no necesitas una estructura jerárquica compleja, es suficiente utilizar colecciones para agrupar los documentos relacionados.

Los datos tienen una relación uno a muchos: Si tienes una relación uno a muchos (por ejemplo, una colección de “productos” y otra colección de “comentarios” donde cada producto tiene múltiples comentarios), usar colecciones separadas puede ser más eficiente y fácil de manejar.

Necesitas consultar o actualizar documentos de manera independiente: Si necesitas realizar operaciones de consulta o actualización en documentos independientes sin tener que considerar documentos anidados, usar colecciones separadas puede simplificar las consultas y las actualizaciones.

Usa Subcolecciones cuando:

Los datos están fuertemente relacionados y tienen una estructura jerárquica: Si tienes datos que están estrechamente relacionados y tienen una estructura jerárquica compleja (por ejemplo, un documento de “pedido” que contiene subdocumentos de “productos” y “envío”), usar subcolecciones puede ayudarte a organizar estos datos de manera más natural.

Necesitas recuperar documentos anidados juntos: Si necesitas recuperar documentos anidados juntos la mayoría de las veces (por ejemplo, obtener un pedido con todos sus detalles de productos y envío), usar subcolecciones puede evitar tener que realizar múltiples consultas para recuperar la información relacionada.

Los documentos anidados tienen un tamaño razonable: Si los subdocumentos tienen un tamaño razonable y no crecerán indefinidamente, puedes considerar el uso de subcolecciones. Sin embargo, si los subdocumentos pueden crecer indefinidamente, puede ser más adecuado tenerlos en colecciones separadas para facilitar el manejo de grandes volúmenes de datos.

• Colecciones (Collections): En NoSQL, una colección es similar a una tabla en bases de datos relacionales. Es un conjunto de documentos relacionados que se almacenan juntos. Cada documento dentro de una colección puede tener diferentes campos y estructuras, lo que lo hace flexible en comparación con las tablas rígidas de las bases de datos relacionales.
  Por ejemplo, si estás construyendo una aplicación de comercio electrónico, podrías tener una colección llamada “productos” que almacena documentos individuales para cada producto en tu tienda. Cada documento podría contener campos como “nombre”, “precio”, “descripción”, etc.
   
• Subcolecciones (Subcollections): Una subcolección es una colección que está anidada dentro de otro documento en una colección principal. Esto permite organizar datos de manera más compleja y estructurada. Es similar a tener una tabla dentro de otra tabla en bases de datos relacionales, pero en un contexto de documentos.
  Siguiendo el ejemplo anterior, dentro de cada documento de producto en la colección “productos”, podrías tener una subcolección llamada “comentarios” que almacena los comentarios de los usuarios para ese producto específico. Cada documento de comentario podría tener campos como “usuario”, “fecha”, “comentario”, etc.

• Los documentos viven en colecciones, que simplemente son contenedores de documentos.
• Una subcolección es una colección asociada con un documento específico.
  https://firebase.google.com/docs/firestore/data-model?hl=es-419

53. Colecciones vs subcolecciones

• Las subcolecciones no viven al nivel de la base de datos.
• Muchas consultas top level collection
• Algo intrínseco al documento, no traer todo al inicio sino hasta que llego al documento. subcollection

consejo importante

La plataforma ha cambiado en interfaz pero el objetivo de tratamiento de BD sigue siendo el mismo…muy buena herramienta firestore

Sub colecciones

La plataforma ha cambiado un poco, ojala pudieran actualizar un poco el contenido

Colecciones vs subcolecciones

Las subcolecciones no están al inicio de la base de datos como las Top Level Collections.

Top level collection

Si es una entidad separada que se va a referenciar desde varios lugares, o se necesita hacer muchas consultas hacia ella se utiliza este tipo de colección.

Subcollection

Si se quiere hacer algo que sea intrínseco al documento y que no se tenga que traer toda la información de inicio, sino hasta que se entra al documento, esto puede ayudar en ser más rápido en red; gastar menos en datos; gastar menos en almacenamiento de la base de datos. Para estos casos se puede utilizar las subcolecciones.

Les voy a mostrar un ejemplo de una app de chat con mensajes y salas de chat.:
Puedes crear una colección llamada rooms para almacenar diferentes salas de chat:

Ahora que tienes salas de chat, decide cómo almacenarás los mensajes. Es posible que no quieras almacenarlos en el documento de la sala de chat. Los documentos en Cloud Firestore deben ser livianos, y una sala de chat podría contener muchos mensajes. Sin embargo, puedes crear colecciones adicionales en el documento de tu sala de chat, como subcolecciones.
Apartir de aqui viene lo interesante

La mejor manera de almacenar mensajes en este caso es usar subcolecciones. Una subcolección es una colección asociada con un documento específico.

Puedes crear una subcolección llamada messages para cada documento de la sala que integra la colección rooms:

Espero que les haiga servido.

Comparto un video de 4 min donde se explican como funionan los OBJETOS y la POO (Programacion Orientada a Objetos) usando como ejemplo el video juego de FIFA:

https://www.youtube.com/watch?v=x7PGl-DJ7RA&list=LL&index=2

Los IDs de Cloud Firestore me siguen confundiendo, incomodan

Colecciones vs Subcolecciones

Top collection va a nivel de la base de datos, mientras que las subcolecciones van dentro de el documento principal.

• Si es una entidad separada que se va a referenciar desde varios lugares o se deben hacer diferentes consultas hacia dicha información, se recomienda hacer uso de la “Top level collection”.
• Si la info solo se quiere ver o almacenar en un documento en especifico de la base de datos, es mejor hacerlo como una sub-colección, ya que es algo que no se va a consultar comúnmente.

Muy interesante.

Es bastante distinto a SQL esto… me está costando verle un sentido.