En esta clase, exploramos cómo transformar estructuras de bases de datos relacionales de SQL en Firestore, un sistema de base de datos no relacional. La transición requiere entender cómo estructurar y manejar los datos con colecciones de nivel superior (top-level collections), documentos, y referencias. A continuación, detallamos los pasos para recrear una base de datos en Firestore aprovechando sus capacidades.
¿Cómo definir colecciones de nivel superior?
Las colecciones de nivel superior son fundamentales en Firestore, ya que funcionan como contenedores que alojan documentos. En el ejemplo del curso, se definieron varias colecciones importantes:
Categorías:
Crea una colección llamada Categorías.
Añade documentos individuales, cada uno representando una categoría con un campo simple para el nombre, por ejemplo: Deportes, Ciencia, Espectáculos.
Las subcolecciones permiten organizar datos relacionados dentro de un mismo documento. En el ejemplo, se mostró cómo agregar etiquetas a cada publicación:
Subcolecciones de Etiquetas:
Dentro de cada Post, crea subcolecciones como Etiquetas que almacenen documentos con el campo Nombre Etiqueta.
La práctica es esencial para dominar Firestore. Intenta replicar esta estructura con tu propio proyecto:
Transformar entidades de SQL a Firestore: Considere cómo sus tablas y sus relaciones pueden convertirse en documentos y referencias.
Practicar las relaciones y la organización de subcolecciones: Familiarízate con las ventajas que ofrece la NoSQL al manejar datos anidados y relaciones no tradicionales.
Explorar otras bases de datos NoSQL: Extiende tu conocimiento a bases de datos similares como MongoDB, que también emplean documentos.
Esta práctica no solo refuerza tu comprensión de Firestore, sino que también te prepara para trabajar con diferentes tipos de bases de datos, cada vez más comunes en el desarrollo profesional. ¡Explora, experimenta y comparte tus resultados con otros para seguir aprendiendo!
Resumen
Emplear colecciones de nivel cero para entidades fuertes, que mas adelante se empleen para realizar busquedas exhaustivas.
Emplear subcolecciones para entidades débiles, que solo permitan plasmar información relacionada, pero que dicha data no sea una fuente de consulta primaria para nuestra aplicación.
Debido a que este es un curso de base de datos no muestran como funciona junto con el backend, al menos no a este punto. En la vida real no hay nadie llenando las bases de datos manualmente, este tipo de base de datos manejan esquemas en ingles scheme es algo asi como una guia para que al momento de guardar la colección sepa como hacerlo adjunto imagen de un schema en MongoDB para un blog sencillo.
Muchas gracias por el vídeo instructor Israel. Mientras estaba practicando el desarrollo de mi proyecto en Firestore, note las siguientes cosas:
Puedes guardar las fechas sin escribir hora alguna quedando por defecto el 00:00:00, así te ahorras algunos segundos mientras añades los documentos.
A medidas que vas agregando colecciones, subcolecciones y documentos, se va volviendo más difícil distinguirlos si usas las Id automáticas proporcionadas por Firebase.
Es sencilla de manejar una vez te familiarizas con la interfaz, pero dependerá bastante de la aplicación a la que se asocie para que pueda ser realmente eficiente al momento de añadir registros.
Por último, comparto una imagen del proyecto hecho en Firestore:
Por si acaso se confunden como yo:
Cloud Firestore a.k.a. Firestore es la base de datos (NoSQL) más reciente de Firebase para el desarrollo de apps para dispositivos móviles.
Firebase es una plataforma para el desarrollo de aplicaciones web y aplicaciones móviles.
Hola! En cuanto a las etiquetas, yo las agregué como Top Level Collections y en los posts creé una subcolección llamada posts_etiquetas que tienen un campo de tipo "reference" y allí coloqué la referencia a cada etiqueta del top level collection :)
Si generas un campo de tipo array es más simple, cada elemento del arreglo debe ser de tipo reference, y como valor pues las etiquetas con las que se relaciona.
No estoy muy seguro de que estos videos mostrándonos como usar una interfaz de firebase sea lo que en verdad necesitamos para aprender bases de datos no relacionales. Este tiempo se pudo haber invertido en cosas mucho más prácticas y que de verdad requieran conocimiento real del tema, porque manejar una base de datos por medio de una interfaz me parece que no requiere mucho skill.
Estimado Profe: Seguí esta clase, con MongoDB, y me encontre con la sorpresa de que esa Base de Datos no soporta de Manera Nativa los JOINs o referencias entre documentos y/o colecciones.... Lo q me hace pensar en el como los datos pueden ser consultados en estos tipos de bases de datos... !!!! Y en lo ORDENADO, que se debe ser, al trabajar con estas Bases de Datos.
Interesante el cambio de paradigma, es notable que debes cambiar tu enfoque al momento de diseñar tu estructura y evitar pensar en relaciones entre entidades.
¡Hola, hola! No soy una experta en el tema. Sin embargo, a diferencia de MySQL donde nosotros realizabamos las consulta con nuestros select, en las bases de datos no relacionales (especificamente MongoDB que es con la que he trabajado) las consultas las hacemos con base en código que escribimos directamente en nuestro sistema con JavaScript, para ello utilizabamos NodeJS. En el caso de firestore, si no me equivoco, también se pueden hacer con NodeJS.
Tengo una dura con Firebase en comparación con MySQL. En MySQL defines inicialmente todos los campos y después ingresas cantenido, por lo que he visto en firebase al agregar los documentos ingresas nombre de campo y contenido. Al consultar los documentos cómo se validan que los nombres de los campos sean los mismos? porque por ejemplo puedo tener un documento con "fecha_publicacion" y otro documento con "fecha-publicacion"
Hola @megadelt, esto no lo valida Firebase por su cuenta, ya que Firebase en NoSQL, no tiene reglas de normalizacion y todos los constrains de MySQL. Entonces esto debes validarlo tú desde el backend o frontend al momento de persistir estos datos