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

1

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

Introducción a las bases de datos relacionales

2

Historia de las bases de datos relacionales

3

Entidades y atributos

4

Entidades de Platzi Blog

5

Relaciones

6

Múltiples muchos

7

Diagrama ER

8

Diagrama Físico: tipos de datos y constraints

9

Diagrama Físico: normalización

10

Formas normales en Bases de Datos relacionales

11

Diagrama Físico: normalizando Platziblog

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

12

¿Qué es RDB y RDBMS?

13

Instalación local de un RDBMS (Windows)

14

Instalación local de un RDBMS (Mac)

15

Instalación local de un RDBMS (Ubuntu)

16

Clientes gráficos

17

Servicios administrados

SQL hasta en la sopa

18

Historia de SQL

19

DDL create

20

CREATE VIEW y DDL ALTER

21

DDL drop

22

DML

23

¿Qué tan standard es SQL?

24

Creando Platziblog: tablas independientes

25

Creando Platziblog: tablas dependientes

26

Creando Platziblog: tablas transitivas

Consultas a una base de datos

27

¿Por qué las consultas son tan importantes?

28

Estructura básica de un Query

29

SELECT

30

FROM

31

Utilizando la sentencia FROM

32

WHERE

33

Utilizando la sentencia WHERE nulo y no nulo

34

GROUP BY

35

ORDER BY y HAVING

36

El interminable agujero de conejo (Nested queries)

37

¿Cómo convertir una pregunta en un query SQL?

38

Preguntándole a la base de datos

39

Consultando PlatziBlog

Introducción a la bases de datos NO relacionales

40

¿Qué son y cuáles son los tipos de bases de datos no relacionales?

41

Servicios administrados y jerarquía de datos

Manejo de modelos de datos en bases de datos no relacionales

42

Top level collection con Firebase

43

Creando y borrando documentos en Firestore

44

Colecciones vs subcolecciones

45

Recreando Platziblog

46

Construyendo Platziblog en Firestore

47

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

48

Bases de datos en la vida real

49

Big Data

50

Data warehouse

51

Data mining

52

ETL

53

Business intelligence

54

Machine Learning

55

Data Science

56

¿Por qué aprender bases de datos hoy?

Bonus

57

Bases de datos relacionales vs no relacionales

58

Elegir una base de datos

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Colecciones vs subcolecciones

44/58
Recursos

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.

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.

Aportes 101

Preguntas 11

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

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

Hay que recordar que las bases de datos NO relacionales nos libran de llevar un schema como lo hace las bases datos relacionales min 2:56. Pero no por eso debemos dejar a un lado el concepto de schema en las bases de datos no relacionales; ya que, en algún momento de vamos a necesitar hacer queries complejas y si no tenemos estructurada la DB nos puede traer demasiados dolores de cabeza en un futuro.
Aquí hay una lectura del blog de Mongo para evitar esta situación:
https://www.mongodb.com/blog/post/time-series-data-and-mongodb-part-2-schema-design-best-practices

También Mongo posee una librería llamada Mongose que nos proporciona un schema.

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

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.

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.

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

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 ^^

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.

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

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

Es importante que en BD no relacionales obviamente la forma entidad relación se pierde, pero OJO hay cosas que no se deben dejar a la deriva, claramente hay que tener un orden lógico, siempre siempre siempre pensando en el modo de consulta para el desarrollador y/o administrador de BD. Por ejemplo el ejemplo claro es mejor crear una sub colección de top level collection que si o solo si van amarradas.

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.

Los documentos en las bases de datos no relacionales brindan mayor flexibilidad al desarrollador...

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.

Para desarrollar ese buen criterio definitivamente se necesitan horas de cancha

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?

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

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

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.

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.

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

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.

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?

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

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… 😜

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

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

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.

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

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

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.

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.

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 😉

Muy interesante.

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

En las bases de datos no relacionales la flexibilidad es un poder, pero este conlleva una gran responsabilidad por que de igual manera tendremos que tener una idea de como se van a almacenar nuestos datos.

Algo que es loco en Firestore es que se ordenan los campos alfabéticamente, sin importar en que orden tu los pusiste

Una coleccion y una subcoleccion se pueden ver como una entidad fuerte y debil, respectivamente, de las RDB.

Al parecer es excelente el servicio de firebase

Muy buen aporte de estos temas, me ha gustado nucho el curso.

Excelente clase.

Capo!

Que gran clase!!! Se aprende mucho en todo momento.

Que diferentes metodologias entre una BD SQL y una No SQL

Colecciones vs Subcolecciones. Firestone es muy bueno

Increible poder traducir de RDB a NORDB 😄

Con base de datos basada en documentos es más fácil guardar la información ya que la estructura de datos es mucho más flexible

Excelente, clase!!!

Me siento en matrix, el profe con un hueco en el saco ya queda como Neo

Muy buena explicación, ahora es explorar con la herramienta.