Cursos Empresas Blog Live Conf Eventos Precios

Dentro de las bases de datos relacionales tenemos diferentes niveles de datos. En primer lugar tenemos las Bases de Datos o Esquemas como repositorios donde vivirán los datos que nos interesa guardar. Dentro del esquema existen las Tablas que provienen del concepto de entidades; y a su vez dentro de las tablas tenemos las tuplas o renglones.

Cuando trabajamos con bases de datos basadas en documentos como Firestore, aún existe la figura de la base de datos, sin embargo cambiaremos las tablas en favor de las colecciones y las tuplas en lugar de los documentos.

Recuerda:

Tabla -> Colección

Tupla -> Documento

Dentro de las Colecciones existen 2 grandes tipos. Las Top level collection o colecciones de nivel superior y las subcollections o subcolecciones. Estas últimas viven únicamente dentro de un documento padre.

¿Cómo saber cuál escoger?

Para determinar si tu colección debe ser top level o subcolección no hay una regla escrita en piedra y más bien tiene que ver con el caso de uso en particular y con la experiencia que hayas ganado como desarrollador.

Lo cierto es que no hay una sola forma de estructurar nuestra DB basada en documentos, y por tanto no existe una respuesta correcta, sin embargo a continuación te ofrezco un par de reglas guía que puedes utilizar para transformar tu proyecto que ya trabajaste en bases de datos relacionales en un proyecto no relacional.

Regla 1. Piensa en la vista de tu aplicación

La primera pista que te puedo dar es que pienses en un inicio en la manera en que los datos serán extraídos. En el caso de una aplicación, la mejor forma de pensarlo es en términos de las vistas que vas a mostrar a un momento determinado en la aplicación.

Es decir, al armar la estructura en la base de datos que sea un espejo o que al menos contenga todos los datos necesarios para llenar las necesidades que tiene nuestra parte visual en la aplicación.

En el caso de Platziblog por ejemplo si tienes una vista de un blog post individual, generalmente conviene mostrar además de los datos inherentes al post como el contenido, datos adicionales como las etiquetas que tiene o por ejemplo el autor (o autores si es colaborativo), en este caso tal vez convenga guardar estas dos “entidades” (autores y etiquetas) como subcolecciones de cada documento blog post.

Regla 2. La colección tiene vida propia

Esta regla se refiere a que la excepción a la regla 1 es cuando tenemos un caso en que la “entidad” que tiene necesidad de vivir y modificarse constantemente de manera independiente a las otras colecciones. Por ejemplo en Platziblog podemos en el ejemplo anterior hacer una excepción a autores porque nos conviene tenerlas como top level collection en el sentido que se añadan, borren, cambien o listen los usuarios sin depender del blog post.

Experimenta aplicando estas dos reglas a un proyecto que ya conozcas en una base de datos relacional y trata de convertirla en un proyecto de Firestore y comentanos los retos a los que te enfrentaste.

Proyecto final: transformando tu proyecto en una db no relacional

Curso de Fundamentos de Bases de Datos 2019

Clase 47 de 58

Clase 47 / 58

Comentarios (179)179 comentarios

Fernando Huamán Santamaria

Hace 7 años

Diego Edgardo Vega Herrera

Muchas gracias, me ayudaste a comprender un poco mejor esto.

Andres Bravo

Muchas gracias por el gran aporte compañero

Carlos Eduardo Gomez García

Hace 6 años

A mi me gustaría añadir una tercera regla:

Regla 3. Piensa a futuro

Es importante igual pensar a futuro al momento de estructurar tu base de datos relacional, porque puede que una estructura pueda solucionarte el problema actual, pero si de repente necesitas hacer modificaciones a tu base de datos y tu estructura no se adapta, la consulta de datos se hará más difícil.

Un ejemplo podría ser que, por ahora guardes los usuarios por posts, pero si más a futuro quisieras mostrar una lista de usuarios que hacen posts, entonces sería más difícil con esa estructura.

Y también compartir algo importante del Curso de Firebase para la Web: Siempre trata de tener la menor cantidad de subcolecciones posibles y prioriza usar las relaciones

Carlos Fernando Aguilar González

Hace 5 años

Hola RetaxMaster

Pienso que tu idea de la tercera regla es muy buena pero, debido a que el proyecto se inicia en el presente, ¿cómo se podría hacer una buena estimación de ese futuro que planteas, es decir, qué debo saber o que datos debo tener en el presente para tener en cuenta esa planeación a futuro?

Saludos

Hablando con tu cliente y preguntarle qué ideas tiene pensadas implementar a futuro, de esa forma puedes darte una mejor idea de cómo estructurar tu base de datos :D

Juan José Calderón

Les comparto mis apuntes de la parte de Bases de datos No Relacionales. ESpero les sirva ;) <3

Victor Luis Landaeta Jimenez

Buen aporte gracias!!

Eric López

Hace 3 años

Gracias por tu aporte...

Daniel Paloma Murcia

En mi caso, estoy trabajando en una App para llevar el control de lectura y libros leídos, con metas diarias, estadisticas y porcentaje de avance del libro. También se pueden crear listas de los libros que están en proceso de lectura.

En Firebase, he creado la colección “books” usando la opción de base de datos “Realtime Database”. Primero creé la tabla en excel (100 registros). Luego la guardé como .csv y la convertí a .json. Finalmente la importé en Firebase.

Alexander Jimenez Sanabria

hola daniel, me parece muy interesante lo que no s cuentas sobre registrar primero los documentos en excel, guardarlo como un CSV y después convertirlos en un Json, nos podrias compartir como lo hiciste, gracias!!

@danielpaloma muchas gracias por los videos

Carlos Eduardo Repillosa Del Valle

La mejor forma para estructurar una base de datos NoSql es a traves del analisis completo de la aplicacion que informacion necesito tener siempre disponible para el usuario, para que la aplicacion cumpla con sus necesidades. Y ademas del analisis de como interactua cada entidad entre si.

JULIO ALFONSO RODRIGUEZ BUELVAS

No se, si sea una correcta aplicación de ambos tipos de bases de datos, pero he llegado a pensar que:

Las No Relacionales, son útiles para consulta en tiempo real.
Las Relacionales, son útiles para crear backup de los datos. Esto pues buscando aprovechar al máximo el uso de ambos tipos de bases de datos en un proyecto. Me gustarías saber que piensan al respecto :).

Puede ser dependiendo del tipo de base de datos que diseñes, puede haber casos en la que una base de datos relacional es más óptima para consultar datos que una base de datos no relacional :D

Muchas gracias Retax.

Así estuve leyendo y aprendiendo en las clases posteriores. Se llega a la conclusión que cuando tus datos son pequeños es mejor usar una base de datos relacional pero si los datos escalan de manera exponencial es mejor migrar a una base de datos no relacional.

Nicolás Morales Samaniego

En esta ocasión apliqué una base de datos para un listado de tortas. En un desarrollo más avanzado ¿Se podría observar las diferentes combinaciones de platillos que puede ofrecer un lugar? Algo así hice en este ejemplo. ¿Es posible realizar operaciones con ciertos datos?

DAVID EDUARDO BAEZ SANCHEZ

Hay que tener claro

Tabla -> Colección

Tupla -> Documento

Y tener claro los dos reglas para una coleccion o subcoleccion.

Nicolas Barragan

Base de datos de la selecciones de futbol: Hice de la ++++selección argentina++++, la idea es ir agrando más selecciones hasta tener todas las CONMEBOL . En SQL:

| Acá un query mostrando algo de la información de las 3 tablas combinadas: |
. Y por último, en la NoQSL, la única top level collection es selección que almacenará a cada una de ellas con su info como campo, y a su vez en ella una sub-collection de jugadores, en la cuál cada jugador tendrá su documento y en él tendrá sus características, y su posición ya agregada. Me pareció más práctico de esta forma en Firestore.

| (Cabe aclarar que solo agregué a Messi, después tengo que seguir con los demás jugadores y selecciones)

Flavio César Sandoval Muñoz

Me encanto la opcion de crear una sub rama para poner el Domicilio creo que es de mucha utilidad esto

Ernesto Ventas Fernandez

Uno de los factores que más se notan es la ausencia de esquema, de modelo de datos con el que poder hacer abstracción y evaluar la consistencia e integridad de las estructuras de datos. Partiendo del modelo E/R, la implementación en Firebase consiste en: Dos Top Level Collection: -lectores -libros

A, continuación, las relaciones múltiples: -lecturas -comentarios Se implementan como sub-colecciones: /libros/lectores /lectores/libros /lectores/comentarios que incluyen las referencias correspondientes a libro y lector.

Edgar Stephen Tellez Garay

intuitiva y facil de usar, creo que hare el cursi de firebase

Cristian Eduardo Samboní Castillo

Hey! Comparteme el curso de Firebase, por favor.

Jhuliana Arango Tobon

Hay tres, tu escoges: https://platzi.com/clases/firebase-cloud/ https://platzi.com/clases/firebase-web/ https://platzi.com/clases/firebase-2017/

Andres Maximiliano Moreira

¿No les parece que este curso pueden ser tres cursos? las bases o principios teórico, la practica sql y luego la práctica nosql...

Anthony Ismael Manotoa Moreno

Hola :)

Este curso pretende ser una introducción justo a eso, pero más adelante sí hay los cursos que mencionas. Te dejo un par de ejemplos:

Sebastian Rodriguez

Hace 4 años

Yo creo que esta perfecto, porque es Fundamentos de Bases de Datos, y Vimos como crear una DB SQL, apredimos las NoSQL, veremos distintos conceptos donde se manejan las DB. Son unas excelentes Bases para ver mas a fondo cada uno.

Lina Hueso

Considero que la mejor manera de comprender una BD basada en documentos, es imaginado un archivero de una secretaria o un bibliotecario, como es más fácil buscar y guardar un documentos en una carpeta (sub-colección) y esta carpeta en que cajón(colección) es mejor guardarla.

Andoni Alonso Tort

Tengo la coleccion libros la cual trae como referencia al autor y al genero y dentro de eso tengo una subcoleccion llamada idioma, la cual muestra el libro en los diferentes idiomas en los que llega y si esta existente o no, además de que dentro de esa subcolección se hace referencia a la editorial por cada idioma. El autor hace referencia a la tabla países según en donde nació.

SCHILDER LENIN RONDAN BRAVO

Para mi proyecto: Comensales: Top Level Platillos: Subcolecciones Bebidas: Subcolecciones Ingredientes: Top Level Carta: To Level Rubros: Subcoleccion La principal duda fue con Ingredientes que pensaba meterla como subcoleccion de platilos y bebidas o como una top level. Al final opte por una top level y referenciarlo en las bebidas y patillos.

Alejandro González Reyes

Desde mi punto de vista profesional, es importante concebir las bases de datos documentales en cuanto a estructura de datos como las API. Recordar que en el mundo de NoSQL no tiene un fuerte impacto las relaciones, por tanto es se hace uso extensivo de subdocumentos (MAP)

Joaquin Fontela

Rosa Martha Núñez Arroyo

Gracias por este extracto de la información que nos has dado, es bastante preciso y concreto. Excelente punto de partida para la creación del nuevo proyecto.

Youssef Abarca

Ver la forma en la cual quiero presentar la información me ayudo mucho para definir la estructura de la base de datos, y creo que para mi aplicación es mejor usar una base de datos de este tipo:

Datos del participante:

Los resultados deben de pertenecer a un participante:

Proyecto final: transformando tu proyecto en una db no relacional

Progreso del curso

Bienvenida conceptos básicos y contexto histórico de las Bases de Datos

Introducción a las bases de datos relacionales

RDBMS (MySQL) o cómo hacer lo anterior de manera práctica

SQL hasta en la sopa

Consultas a una base de datos

Introducción a la bases de datos NO relacionales

Manejo de modelos de datos en bases de datos no relacionales

Bases de datos en la vida real

Bonus