Recreando Platziblog

me siento como en dora la exploradora, a veces, respondiendole a una pantalla…

Notas Las bases de datos no relacionales, no están optimizadas para hacer “queries”, sino mantener el estado de la aplicación por ende si se desean luego hacer reportes en la aplicación de diferentes datos, no es recomendable usar BD NoSQL

Firestore, es una base de datos basada en documentos, pensada en lo siguiente:

• Mantener el estado de tu aplicación.
• En como se verán reflejados los datos en el frontend para el usuario.

Podemos hacer consultas sencillas en base a las top level collecttion. Ahora si queremos hacer consultas mas complejas podríamos usar big query, que es un data wharehouse.

Según lo comentado en esta clase, considero que tener una base de datos SQL es una mejor solución y me baso en lo siguiente:

1. Tener una base de datos normalizada, es tener una solución mas general y preparada para el crecimiento de una aplicación. Por ejemplo en la app de blogs aunque para los requisitos actuales de la aplicacion este mejor tener a usuarios como una subcoleccion de posts, a futuro esto no va a ser necesariamente cierto, y sera un dolor de cabeza realizar ese cambio pues implicaria realizar migraciones de datos.

2. Por lo general si una aplicación crece en algún punto va a necesitar reportes, lo cual conlleva a consultas complejas para las cuales esta mejor preparada una base de datos SQL.

Hola, sáquenme de una duda. ¿Por que el prof en ocasiones le dice “Firestore” a “Firebase”? ¿Son la misma cosa?

MENSAJE PARROQUIAL Y SALVAVIDAS…
No diseñar sistemas de bases NoSQL como sistema relacional.

Notas:

• Las bases de datos basadas en documentos no están pensadas para hacer reportes complejos (querys)
• Son pensadas para guardar datos y recuperarlos de una manera secuencial (en aplicaciones o juegos)

Es la primera vez que trabajo de manera tan flexible con BD, después de tantos años acostumbrando trabajar con normalización, esto me resulta totalmente nuevo y es como dejar a las palomas salir de su jaula jajaja

Yo todavía me sigo preguntando si manejar un dato tipo JSON en postgresql con el mismo motor o usar FireStore para almacenar esos documentos.

Lo importante como dice Israel, al final tanto las sql como las nosql sirven para lo mismo, almacenar datos, pero cada una maneja un estilo y una característica particular, ya depende del proyecto y del desarrollador decidir la que mejor se adapte al mismo. Mi proyecto me comió la cabeza buscando las entidades y las relaciones, con firebase la cosa cambia y al final noto mejores resultados usando la nosql. Como todo en esta vida, para gustos, colores

Las bases de datos no relacionales son muy flexibles y la organización de la información dependerá de las consultas que se deseen realizar. Un gran poder conlleva una gran responsabilidad, organizar los datos de manera correcta. 💚

La ventaja de las No SQL es que son rápidas.

Me parece que hay 2 quotes memorables de esta clase:

Ambos tipos de bases (SQL y NoSQL) cumplen el mismo objetivo, guardar datos.

Las bases de datos relacionales están pensadas en hacer queries, mientras que las noSQL están pensadas en mantener el estado de tu app.

Como aplicar top level collection y sub collection: En las bases de datos NoSQL depende mucho pensar en como se van a consultar los datos es decir si necesitamos realmente crear un documento de tipo top level collection o si lo podemos colocar como sub collection que es decir que viva dentro de un documento. pero el requisito general que se requiere al crear cualquier tipo de bases de datos es ver todo el lineamiento en una sola vista.

Excelente clase instructor Israel, así qué debemos pensar muy bien como se estarán usando cada una de las entidades dentro de una aplicación para poder decidir si son colecciones o subcolecciones, como destaco con la entidad de usuarios puede estar como subcolección pero como se va usar en otros lugares fuera del posts por ejemplo al iniciar sesión, opino que es mejor dejarla como una colección.

Me llama mucho la atención este tópico de las NOSQL BDs , Siguiente curso: MongoDB

Buenas Noches.
A qué se refiere con una Colección de Top Level Collection por favor?

Gracias.

Este video me aclaró algunas dudas:
https://firebase.google.com/docs/firestore/data-model

Supongo que el arte de aprender a ingresar los datos de una manera práctica basándonos en nuestras preferencias es cuestión de práctica porque la verdad aunque el profesor lo hace ver fácil a la hora de la práctica puedo bloquearme un poco sin experiencia.

Creo que este aporte sirve mucho para definir cuando utilizar un top level collection y cuando no.

Un top level collection se utilizaría para relaciones de tipo “agregación”. Mientras que una sub collection se utilizaría para relaciones tipo “composición”.
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.

Las NOSQL son muy flexibles, hay que saber en que aplicaciones usarlas.

• No se deben dejar datos por fuera, se debe buscar como “traducir” los tipos de información.
• Se debe analizar cuál es la entidad que se debe dejar como una top level collection y cuál hace mas sentido dejar como una colección dependiente de los documentos.
• Este tipo de bases de datos (basadas en documentos) no están pensadas para resolver queries, están pensadas para mantener el estado de la app. Si se requiere hacer queries, lo mejor es hacer uso de bis query.

Genial, aunque yo adicional a esto, también añadiría una recomendación de pensar a futuro, por ejemplo, si a futuro de repente quieres tener una lista de usuario, y dejaste los usuarios dentro de la colección de posts entonces podría volverse más complicado

Hay tanto que aprender…

Vamos a ello!

uff… todo depende de como lo queramos ver y que tipo de info quieras sacar de la Base de Datos

interesante!

Excelente explicación!!

Buena explicacion, concisa, resumida excelente profe

39. Mis apuntes sobre: “Recreando Platziblog”

Se debe analizar si usar o no una top level collection o una subcolección.

Interesante esto de no relacional

Interesante el enfoque que se le debe dar al diseño de la base de datos, algo muy direrente a las bases de datos relacionales.

Gracias!

Hay que saber bien en qué momentos usar una u otra solución. Me topé con empresas donde se subieron al carro de las BD NoSQL porque estaba de moda, y luego de un tiempo tuvieron que volver a usar la vieja y confiable MySQL, no digo que una sea mejor que otra, pero a cada problema su solución 😃

mis apuntes de la Clase:
https://github.com/DanielGB00/fundamentos-BD#recreando-platziblog

Hasta ahora más o menos lo entiendo así:

BD Relacionales >>> Tablas
BD No relacionaes (por documentos) >>> Árbol

Espero no estar uy perdido 😁

En la sección de Bases de datos relacionales se Expresaron conceptos de Entidades Fuertes y Entidades Débiles, Lo que el profe dice es lo correcto que depende del tipo de uso que se le desee dar. Pero en general creo que para que el sistema sea mas expansible y fácil de consultar, Las Entidades fuertes se deben asimilar como Colecciones Top y las Entidades Débiles como Sub colecciones.

MongoDB se está actualizando constantemente y cada vez mejoran sus herramientas de búsqueda. Al menos en lo visto en este curso (y sosas más complejas) no he encontrado algo que puedas hacer con MySQL que no puedas hacer con MongoDB.
Yo les recomiendo que exploten y que no se queden con la idea estricta de que no es posible hacer algún query complejo con bases NoSQL.
Lo bello de esta industria es que todos los días cambia.

Como decidir una TOP LEVEL COLLECTION:

Si convertimos la Entidad posts a una top level colection, y dentro de la colección:posts ponemos una sub-colección:usuarios, esto hará una búsqueda más rápida de los posts pero más “lenta” al buscar que usuario a creado algún posts.

Ambas aproximaciones son correctas, todo depende de que información requieres en una vista.

Entonces las RDBMS son mas para por ejemplo si quieres presentar la información en un documento de excel para tratar esos datos de forma independiente y las NO-SQL servirían mas para por ejemplo en una pagina web o aplicación movil nomas quieres presentar la info para que el usuario la vea?
Si alguien pudiera resolverme la duda me quedaría mucho mas claro el tema, muchas gracias!

En resumen una base de datos orientado a documentos no es útil para hacer consultas. Si no para tener un buen estado de nuestra aplicaciones.

Excelente explicación sobre la necesidad de las bases de datos basadas en documentos y su relación inversa con las relacionales.

Quedo muy claro y bien explicado, en la practica es en la que se puede explorar mas a fondo y se van resolviendo dudas. Gracias.

Cada documento de Cloud Firestore se identifica de forma única por su ubicación dentro de la base de datos. El ejemplo anterior muestra un documento alovelace en la colección users. Para hacer referencia a esta ubicación en tu código, puedes crear una referencia a ella.

Para entender este paradigma, necesariamente debemos repasar JSON, y es parte de los Fundamentos:

Tanto para SQL como para NoSQL, la creación de una base de datos estructurada de forma adecuada requiere bastante previsión.

La parte más importante es planificar cómo se guardarán y recuperarán los datos para que el proceso sea lo más simple posible.

Los datos en Firebase NoSql se estructuran como un árbol JSON. Cuando le agregas datos al árbol JSON, estos se convierten en un nodo de la estructura JSON existente con una clave asociada

La decisión de volver una entidad una colección o subcolección depende del desarrollador. En este caso, si se necesitan usualmente los datos de usuario, se deja como colección. En caso contrario, se puede dejar como subcolección de los posts.

Mi top level quedó asi en mi proyecto:
Top level
TPC vendedores/
tienda/productos/categorias/etiquetas
ventas
TLC usuarios:
Membresia
compras/Calificaciones

No pensé empezar a comprender algo que en un punto veía tan complejo, muy buenas clases
Gracias Platzi.

Un excelente ejercicio para este caso, sería modelar la DB de Wordpress 😃

Es importante declarar cual va a ser el uso y la naturaleza de la base de datos

se ve facil

Me propongo trabajar todo lo que el profesor sugiere. Estoy motivado

interesante clase

Muy claro todo.

Buenas clase. Hay que tener claro la funcionalidad y asi poder determinar las colecciones o subcolecciones

Tener en claro lo que se va a desarrollar y como guardaremos nuestros datos es primordial a la hora de elegir nuestra DB.

manos a la obra

esto es genial y muy intuitivo

El orador plantea la transición de una base de datos relacional (como SQL) a una base de datos no relacional (Firestore) y discute cómo se pueden estructurar los datos en Firestore. Se enfoca en cómo decidir si una entidad debe ser una colección independiente o una subcolección de documentos, como usuarios, posts, comentarios, categorías y etiquetas. El orador enfatiza que ambas aproximaciones son válidas, pero dependen de las necesidades específicas del caso de uso y la forma en que se accederá a los datos.

En resumen

• Firestore permite una flexibilidad en la estructuración de datos y no se centra en la realización de consultas complejas como las bases de datos relacionales. En cambio, se debe considerar cómo se reflejarán los datos en el frontend de la aplicación y cómo los usuarios interactuarán con ellos. Las estructuras de datos en Firestore pueden ser diferentes a las de SQL, pero ambas bases de datos sirven para almacenar información.

Cuando eres un programador junior estas clases te ayudan demasiado a avanzar.

estoy algo perdido, pero esta bien, fireStore quiero verlo por encima, en realidad queiero echarle muela a Elastic

Las bases de datos no relacionales a diferencia de las relacionales donde se pueden realizar queries, están más pensadas para mantener el estado de tu aplicación

gracias

usuarios
post
comentarios
categoria
etiquetas

Buen Maestro!

usar o no una DB Relacional o una NoSQL, definitivamente depende mucho de que necesitamos. Tenemos soluciones orientadas a muchas necesidades distintas y depende de cada caso saber cual funcionaria mejor.

Las BD NoSQL a base de documentos no estan pensadas para hacer queries, si queremos usarlo dentro de las BD NoSql podemos usar BigQuery; o en su defecto las BD Relacionales

Usar Bases de Datos SQL o NOSQL va a depender del proyecto y la manera en cómo sera planteado

Cada vez percibo que hay mucho que aprender.

Estos modelos sirven más para mantener el estado de la aplicación.

Excelente contenido. Israel es un profesor de categorías altas, hasta ahora de mis favoritos de Platzi.

bien

wow this is excellent

No dejes de lado ningún dato!

Con Firebase, NO necesitaras la construcción de web services, api rest, configuración del servidor.

Gran pre explicación !!.

Excelente…

Para queries complicados no es muy recomendable usar usa DB de documentos.

Las BD No SQL, no son muy utiles para hacer querys complejos

manos a la obra!

Firebase funciona como una flexible api rest

Lo que entiendo es que en las BD NoSQL vamos a pensar en orden de saber qué vamos a necesitar. La normalización de la BD no es un requisito.

Gracias

Motivado

Me parece que al ser tan flexibles no hay una forma de trabajar con estas DB de manera standard ademas la multitud de ellas para un uso especifico no se que esperar, o tal vez es solo el cambio de paradigma desde las DB relaciones que me esta costando entender

No lo se la sensación que me quedo es: mete todos en el Documento Post y no intentes hacer consultas complejas de la información.
Entiendo que basado en una arquitectura de desarrollo de tres capa, no se requiere de tener validaciones fuertes en base de datos y que preferimos que nos conteste mas rápido la información, para que la capa de negocio de encargue de acomodar y convertir lo que se presentara después en pantalla.

No todas las bases de datos no relacionales están optimizadas para hacer queries, pero algunas si como Big Query

al final tanto las sql como las nosql sirven para lo mismo, almacenar datos, pero cada una maneja un estilo y una característica particular, ya depende del proyecto y del desarrollador decidir la que mejor se adapte al mismo.