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

Qué son 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

Instalación local de un RDBMS (Windows)

13

¿Qué es RDB y RDBMS?

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 y SQL JOINs

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

El interminable agujero de conejo (Nested queries)

36/58
Recursos

Los Nested queries significan que dentro de un query podemos hacer otro query. Esto sirve para hacer join de tablas, estando una en memoria. También teniendo un query como condicional del otro.

Este proceso puede ser tan profundo como quieras, teniendo infinitos queries anidados.
Se le conoce como un producto cartesiano ya que se multiplican todos los registros de una tabla con todos los del nuevo query. Esto provoca que el query sea difícil de procesar por lo pesado que puede resultar.

Aportes 159

Preguntas 31

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

o inicia sesión.

Mi resumen de todo esto es el siguiente:

  • Las consultas anidadas son la mejor opción cuando los valores dependen de otras tablas, y estas no se encuentran relacionadas entre si.

  • Las consultas anidadas son la mejor opción para casos de INSERT, DELETE, UPDATE, cuya condición dependa del esenario explicado en el punto anterior

  • Los JOINS son la mejor opción para casos de SELECT

Es increible la capacidad que tienes de reflejar tu conocimiento, ha sido una gran experiencia este curso Israel, yo habia hecho lo que has explicado, pero de manera empirica, muchas veces por inercia y al calor del momento de presion laboral pues te forjas, pero considero que el deber ser es teniendo unas solidas bases como las que proyectas, y no queda mas que de nuestro lado como estudiantes hacer practica y estar “jugando” con los datos y ver y documentar el comportamiento de los queries que hagamos.

Saludos.

Query aninado

SELECT title, date_publi, status
FROM posts
WHERE date_publi = (
SELECT MAX(date_publi)
 FROM posts
);

Query normal

SELECT title, date_publi, status 
FROM posts
ORDER BY date_publi DESC LIMIT 1;

Nested queries

Significan que dentro de un query podemos hacer otro query. Esto sirve para hacer join de tablas, estando una en memoria. También teniendo un query como condicional del otro.
.
Este proceso puede ser tan profundo como quieras, teniendo infinitos queries anidados.
Se le conoce como un producto cartesiano ya que se multiplican todos los registros de una tabla con todos los del nuevo query. Esto provoca que el query sea difícil de procesar por lo pesado que puede resultar.
.
Ejemplos:
SELECT new_table_projection.date, COUNT(*) AS post_count
FROM (
SELECT DATE(MIN(fecha_publicacion)) AS date, YEAR(fecha_publicacion) AS post_year
FROM posts
GROUP BY post_year
) AS new_table_projection
GROUP BY new_table_projection.date
ORDER BY new_table_projection.date;
.
SELECT *
FROM posts
WHERE fecha_publicacion = (
SELECT MAX(fecha_publicacion)
FROM posts
);

Apuntes:
Una nested query sirve para hacer una consulta dentro de otra consulta (normalmente dentro de la sentencia FROM o WHERE), esto funciona como alternativa para los JOIN o como condicional de un query dentro de otro. La profundidad de un nested query es infinita, por lo que se pueden hacer infinidad de consultas dentro de otras. El punto negativo de esto, es que puede volverse lento a la hora de ejecutar.

me hace recordar a las condiciones anidadas en programación, que tampoco se recomienda su uso por volverse confuso en un momento determinado y poco escalable

NESTED QUERIES o Consultas o queries anidados.
'
Muy interesante. Pero considero que solo se debe aplicar cuando sea realmente necesario, este tipo de queries deben de consumir buena memoria en el momento de la ejecución cuando las bases de datos son muy robustas.

-- Crear una tabla con el campo fecha, que los cuente, los agrupe y los ordene por el 
-- campo fecha. La información se extraerá de la tabla posts y la fecha mínima de cada año.
Select NuevaTabla.Fecha, Count(*) As Cant
From (
	Select Date(Min(fecha_publicacion)) As Fecha, Year(fecha_publicacion) As Año
	From posts
    Group By Año
) As NuevaTabla
Group By NuevaTabla.Fecha
Order By NuevaTabla.Fecha;

-- Mostrar de la tabla posts la fecha máxima o las más actual.
Select * From posts
Where fecha_publicacion= (
	Select Max(fecha_publicacion)
    From posts
);

Los Nested Queries pueden ser de gran utilidad cuando se trata consultas de considerable complejidad. Sin embargo no se deben utilizar indiscriminadamente, sino aplicarlos según un determinado contexto.

Esta es una de mis Query que utilizo en mi trabajo para revisar si los datos están

SELECT *
  FROM caracteristicas_lotes cl
WHERE NOT EXISTS
         (SELECT 1
            FROM historico_lotes hl
           WHERE hl.codigo_empresa = cl.codigo_empresa
             AND hl.codigo_articulo = cl.codigo_articulo
             AND hl.numero_lote_int = cl.valor_alfa_2)
   AND cl.codigo_empresa = '004'```
 bien asignados:

NESTED QUEREIS consiste en seleccionar información de una tabla temporal que acabamos de crear con un Query.
También se puede decir que es un Query anidado.

Se debe tener cuidado con los querys anidados ya que la complejidad computacional puede crecer de forma exponencial de acuerdo al número de registros O(n) = n^N. Se debe tener cuidado de hacerlo en querys no escalables.

En lo personal prefiero meter los sub query en una función y reutilizarlos de ser necesario

¿Qué diferencia hay entre una tabla temporal local y una tabla temporal global?

seria como bucles voraces que jalan bastante memoria básicamente!! ujumm

Los Nested queries significan que dentro de un query podemos hacer otro query. Esto sirve para hacer join de tablas, estando una en memoria. También teniendo un query como condicional del otro.

Recomiendo estos ejercicios que encontre, realmente utiles para fianzar conocimientos sobre subconsultas

https://josejuansanchez.org/bd/ejercicios-consultas-sql/index.html#base-de-datos-para-mysql

En este ejemplo se busca el ultimo usuario en registrarse al gym

Este proceso puede ser tan profundo como quieras, teniendo infinitos queries anidados.
Se le conoce como un producto cartesiano ya que se multiplican todos los registros de una tabla con todos los del nuevo query. Esto provoca que el query sea difícil de procesar por lo pesado que puede resultar.

Los nested querys consumen muchos recursos de memoria, debido a que los resultados de la tabla anidad se guardaran temporalmente mientras se ejecuta la consulta. Si la consulta anidada no esta lo suficientemente filtrada puede tardar mucho en traer los resultados.

SELECT name_product, product_description, image_url, barcode, id_pharm, name_category
FROM (
	SELECT name_product, product_description, image_url, id_category, barcode, id_pharm
	FROM (
		SELECT id_product, barcode, id_pharm
		FROM barcodes_products
		WHERE amount > 0
	) AS data_id_filter
	LEFT JOIN products on products.id_product = data_id_filter.id_product
) as id_table
LEFT JOIN product_categories ON product_categories.id_category = id_table.id_category

Mi query mas loco y funciona en mi proyecto. Le estoy trabajando a una framacia. Este es el resultado. WIII!

Esto se me acaba de ocurrir. Me muestra la lista de alumnos con una nota mayor al promedio.

SELECT * FROM alumnos WHERE nota > (
	SELECT AVG(nota) FROM alumnos
)

30. Mis apuntes sobre: "El interminable agujero de conejo (Nested queries)"
Los queries anidados / nested queries, se usan cuando tienen un problema que
no se puede solucionar solo consultando. No conviene abusar de ellos, debido a que
no es escalable, y hace un uso exponencial de los recursos.

-1. Ejemplo de Código SQL:

SELECT new_table_projection.date,
COUNT(*) AS posts_count
FROM (
	SELECT DATE(MIN(fecha_publicacion)) AS DATE, YEAR(fecha_publicacion) AS post_year
    FROM posts
    GROUP BY post_year
) AS new_table_projection
GROUP BY new_table_projection.date
ORDER BY new_table_projection.date;

-2. Ejemplo de Código SQL:

SELECT *
FROM posts
WHERE fecha_publicacion=(
	SELECT MAX(fecha_publicacion)
	FROM posts
);

Yo las conocia como Sub Query, son bastante buenas y generan flexibilidad

excelente!!!

bastante interesante, creo que en un futuro no muy lejano profundizare en Nested Queries

En platzi tenes profesores que te hacen cortar el video, irte a estudiar por tu cuenta, y volver al curso no para verlo, sino para tomar el examen. después hay profesores como israel que te hacen querer seguir haciendo cursos de el xD.
Alguien me dice que otros cursos tiene?

Otra forma de hacer el último query sin necesidad de anidar:

SELECT * 
FROM posts 
ORDER BY fecha_publicacion DESC 
LIMIT 1;

El interminable agujero de conejo (Nested queries)

La idea fundamental de los Nested queries es que se puede tener un query dentro de otro query.

¿Cuándo ocupar los Nested queries?

  • Cuando tienes un problema que no se puede solucionar simplemente consultando una tabla, o que tiene algunas condiciones que no te permiten obtener los datos que necesitas.
  • Se debe tener cuidado utilizando los Nested Queries sin tener en cuenta la escalabilidad de estos. También, se puede caer en un Producto Cartesiano, es decir, se esta haciendo una multiplicación de los registros que estas obteniendo.

Sentencias ejemplo

select new_table_projection.date, count(*) as `posts count`
from (
	select DATE(MIN(release_date)) as date, YEAR(release_date) as post_year
	from post
	group by post_year
) as new_table_projection
group by new_table_projection.date
order by new_table_projection.date;

Es muy común utilizar este tiempo de query cuando se necesita obtener valores máximos o mínimos de alguna tabla.

select * 
from post
where release_date = (
	select max(release_date)
    from post
);

Recomendaciones

  • Si se pretende que un query tenga escalabilidad, no es recomendable utilizar este tipo de queries.

Es como los pipes en línea de comandos, donde la salida de un comando es la entrada de otro.

COMMANDS THAT USE THE TEACHER IN THIS CLASE:

SELECT new_table_projection.date, COUNT(*) AS posts_count
FROM(
SELECT DATE(MIN(fecha_publicacion)) AS date, YEAR(fecha_publicacion) AS post_year
FROM posts
GROUP BY post_year
)AS new_table_projection
GROUP BY new_table_projection.date
ORDER BY new_table_projection.date;

SELECT *
FROM posts
WHERE fecha_publicacion = (
SELECT MAX(fecha_publicacion)
FROM posts
);

select new_table_projection.date, count(*) as post_count
from (
select date(min(fecha_publicacion)) as date, year(fecha_publicacion) as post_year
from posts
group by post_year
) as new_table_projection
group by new_table_projection.date
order by new_table_projection.date;

select *
from posts
where fecha_publicacion = (
select max(fecha_publicacion)
from posts

);

La complejidad permite crear consultas o extracción de información más completa, todo depende del buen uso de los querys anidados, bien estructurados y mantener una lógica adecuada para obtener los resultados necesarios.

Este otro ejemplo, recupera todas las publicaciones que contienen como etiqueta a JAVASCRIPT.
En este caso hay una relacion de muchos a muchos, y por tanto intervienen tres tablas

SELECT titulo FROM publicaciones WHERE id IN
(SELECT publicacion_id FROM etiquetas_publicaciones WHERE etiqueta_id = 
(SELECT id FROM etiquetas WHERE nombre = "JAVASCRIPT")
);

Muy interesante este tema, tengo varios años de haber llevado el curso de base de datos en la universidad y aún no conocía todo el potencial de las nested queries.

Muy buen tema!

excelente clase estoy maravillado con este curso

Excelente video

Super densos, para mi es mas dificil la anidación de las consultas, que los for’s anidados.

SQL no pasara de moda; sus recursos son increíblemente adaptables a cualquier requerimiento, 🛢⚙📈

Algunos aportes sobres los sub queries.

  • Las subconsultas deben estar entre paréntesis.

  • Una subconsulta solo puede tener una columna en la cláusula SELECT, a menos que haya varias columnas en la consulta principal para que la subconsulta compare sus columnas seleccionadas.

  • Un comando ORDER BY no se puede usar en una subconsulta, aunque la consulta principal puede usar ORDER BY. El comando GROUP BY se puede utilizar para realizar la misma función que ORDER BY en una subconsulta.

  • Las subconsultas que devuelven más de una fila solo se pueden usar con operadores de valores múltiples, como el operador IN.

  • La lista SELECT no puede incluir ninguna referencia a valores que se evalúen como BLOB, ARRAY, CLOB o NCLOB.

  • Una subconsulta no se puede encerrar inmediatamente en una función establecida.

  • El operador BETWEEN no se puede utilizar con una subconsulta. Sin embargo, el operador BETWEEN se puede utilizar dentro de la subconsulta.

Para el que tenga curiosidad aquí esta una imagen de Big O notation.

Se puede observar como la complejidad algorítmica empieza a crecer cada vez más.

Query anidado

select * from posts
where fecha_publicacion = (SELECT MAX(fecha_publicacion) FROM posts)
tiempo de consulta aproximado: 5.1 ms

Query normal
__select id, titulo, MAX(fecha_publicacion), estatus, contenido from posts
tiempo de consulta aproximado: 4.3 ms
__

restringiendo los registros con Limit
SELECT id, titulo, estatus, contenido
FROM posts
ORDER BY fecha_publicacion DESC LIMIT 1;
tiempo de consulta aproximado: 4.5 ms

Observacion: en tablas con pocos registros no se puede observar las diferencias entre los tiempos de la consulta mas sin embargo en tablas con demasiados registros si. por lo tanto es necesario tenerlo en cuenta a la hora de realizar consultas anidadas, en lo posible evitarlos si se puede optimizar la consulta.

Los nested queries son queries anidados (una consulta dentro de otra consulta) son muy útiles en casos puntuales
.
Como hacer una tabla que haga un JOIN con otra tabla y esta sera una tabla que existe únicamente en memoria que sirve también para hacer un JOIN con una tabla existente en la base de dato.
.
Como el resultado final de un queries en una condición de un WHERE.
.
Generalmente se utilizan los nested queries cuando se tiene un problema en especifico que no se puede solucionar solo consultado la tabla en la base de datos y se necesita agregar o hacer otro tipo de operación que viene de otra tabla o de la misma tabla y al momento en que se agrupa no se puede hacer un queries de un WHERE que tiene otra condición.
.
A medida que los datos empiezan a crecer y existen 1.000 0 1.000.000 de datos para hacer queries, cuando se hacen nested quieres se crea un producto cartesiano que tiene que ver con la multiplicación de todos los registros de una tabla con todos los registros del nuevo queries dentro una vez por cada uno. Entonces esta anidación genera que el queries sea demasiado pesado y difícil de procesar para el RDBMS (depende del servidor, de la capacidad de computo) como característica general tiene que no escala y se va a una question de notación exponencial. Por cada queries que se realice en el queries padre va a realizar una cantidad de queries en el queries hijo, por cada que aumente un registro en uno va a aumentar una cantidad de veces en el queries hijo, por lo que se multiplica y crece exponencialmente.
.
los nested queries son útiles en situaciones particulares en las cuales ese queries no es escalable, ni crece constantemente la tabla sobre la cual se realiza.

En mi caso me costo un poco entenderlo al principio, acá dejo un ejemplo.

select nombre_del_otro_select.alias
from(
	select (min(fecha_publicacion)) as alias	
    from posts) as nombre_del_otro_select;

nombre y alias pueden tener el nombre que sea, pero debe ser el mismo en ambos casos y debe estar

Los nested queries significan que dentro de un query podemos hacer otro query. Esto sirve para hacer join de tablas, estando una en memoria. También teniendo un query como condicional del otro.

Ejemplo 1

SELECT new_table_projection.date, COUNT(*) AS posts_count

FROM (

SELECT DATE(MIN(fecha_publicacion)) AS date, YEAR(fecha_publicacion) AS post_year

FROM posts

GROUP BY post_year

) AS new_table_projection

GROUP BY new_table_projection.date

ORDER BY new_table_projection.date;

Hola quisiera saber si hay alguna otra forma de hacer esto mas facil

👀Si hacen consultas aninadas (nested queries) garanticen que estén lo más optimizadas posibles. Si no, cuando crezcan los datos será un gran problema.

Producto cartesiano, querys anidados,
hace la multiplicación de un tabla con todos los registros de la otra tabla una ves por cada registro.

Entonces los posts_count simpre van a devolver 1 no ?por que siempre trae el primer post de cada año o me equivoco?

Gracias por la clase instructor Israel, ahora tenemos otra herramienta más para hacer consultas, incluso para crear tablas en base a las que tenemos almacenadas, pero debemos tener en cuenta en el futuro si la aplicación en las que usemos escalaran bastante, si es así es mejor usar unas más sencillas para que no comprometa su efectividad.

Esto lo he usado, también para hacer varias cosas, usarlas como campos adicionales osea SubVistas, Joins, condiciones osea en el Where, esos son los tipos de cosas que he hecho con los Nested Queries

llega un momento en el que si son varios subquerys la consulta se demora mucho tiempo o simplemente se queda ejecutando.
No obstante he escuchado hablar del comando WITH.
Como se utiliza? y que tan bueno es al momento de usar bastantes subqueries?

select new_table_projection.date,count(*) as post_count
from (
select date(min(fecha)) as date, year(fecha) as publicaciones_year from publicaciones
group by publicaciones_year
) as new_table_projection
group by new_table_projection.date
order by new_table_projection.date
;```
Por lo que estoy entendiendo podemos guardar una tabla resultante de una consulta con la instruccion "as". Esta tabla quedara en memoria y podremos llamarla al inicio de la consulta en nuestro primer select. Al parecer el DBMS guarda las intrucciones y las tablas en memoria para ejecutarlas luego

select new_table_projection.date_p,count(*) as post_count
from
(select date(min(fecha)) as date_p, year(fecha) as publicaciones_year from publicaciones
group by publicaciones_year
) as new_table_projection
group by new_table_projection.date_p
order by new_table_projection.date_p
;

Hacer esto igual funciona 
Si estoy mal acepto el feedback
`select sUserName, sUserID, sDepartment
, DATEADD(DAY, DATEDIFF(DAY, 0, DATEADD(second, nDateTime, '19700101 00:00:00')),0) AS Fecha
, CONVERT(TIME, DATEADD(second, nDateTime, '19700101 00:00:00')) AS Horaini
 from TB_EVENT_LOG E join TB_USER U on E.nUserID = U.sUserID
 join TB_USER_DEPT Dep on Dep.nDepartmentIdn = U.nDepartmentIdn
 WHERE nDateTime > datediff(second, '19700101 00:00:00',
CAST(YEAR( '19700101 00:00:00') AS NVARCHAR(4)) +
FORMAT(MONTH( '19700101 00:00:00'),'0#') +
FORMAT(DAY( '19700101 00:00:00'),'0#') +
' 00:00:00')  
AND nEventIdn IN (23, 55,119)  order by Fecha, sUserName````

No me funciono
select new_table_projection.date, count(*) as posts_count
from(
select date(min(fecha_publicacion)) as date, year(fecha_publicacion) as post_year
from posts
group by post_year)as new_tale_projection
group by new_table_projection.date
order by new_table_projection.date;

common table expression (CTE)
CTE is a named temporary result set that exists within the scope of a single statement
and that can be referred to later within that statement, possibly multiple times.

WITH cte_usuarios
as
(
	select t1.id
		,t1.nickname
    from usuarios as t1
)
select t1.id
	,t1.titulo
	,t2.nickname Usuario_que_hizo_el_post
    ,t3.cuerpo_comentario
    ,t2.nickname Usuario_que_hizo_el_comentario
from posts as t1
	inner join cte_usuarios as t2
		on t1.usuario_id = t2.id
	inner join comentarios as t3
		on t1.id = t3.post_id
	inner join cte_usuarios as t4
		on t3.usuario_id = t4.id;
        

Este ejemplo, recupera los titulos de las publicaciones que pertenecen a la categoría Back End, cuyo nivel es Básico, y email de usuario se corresponde con [email protected] (consulta en tres tablas)

SELECT publicaciones.titulo FROM publicaciones WHERE categoria_id = 
(SELECT id FROM categorias WHERE nombre = "Back End") 
AND nivel_id = 
(SELECT id FROM niveles WHERE nombre = "Básico")
AND usuario_id = 
(SELECT id FROM usuarios WHERE email = "[email protected]");

Para reforzar el tema, una consulta anidada es similar a un JOIN, pero con la sutileza que el resultado se almacena en memoria por cada query anidado, consumiendo mayor numero de recursos.

  • Seleccionar las publicaciones del usuario con correo [email protected]. (considerando que hay dos tablas relacionadas publicaciones y usuarios)…
SELECT titulo FROM publicaciones WHERE usuario_id = (
SELECT id FROM usuarios WHERE email = “[email protected]”);

Modifique la consulta para que me regrese la primera y la ultima publicación de cada año.

SELECT monthname(fecha_publicacion) AS mes_de_publicacion, titulo , fecha_publicacion
FROM posts
WHERE fecha_publicacion IN (
	SELECT MAX(fecha_publicacion) AS maximo
    FROM posts
    GROUP BY YEAR(fecha_publicacion)
) OR fecha_publicacion IN (
	SELECT MIN(fecha_publicacion) AS minimo
    FROM posts
    GROUP BY YEAR(fecha_publicacion)
)
ORDER BY YEAR(fecha_publicacion), MONTH(fecha_publicacion);

First of all, you can put a nested SELECT within the WHERE clause with comparison operators or the IN, NOT IN, ANY, or ALL operators. The second group of operators are used when your subquery returns a list of values (rather than a single value, as in the previous example):

The IN operator checks if a certain value is in the table returned by the subquery.
The NOT IN operator filters out the rows corresponding to the values not present in that table returned by a subquery.
The ANY operator is used with comparison operators to evaluate if any of the values returned by the subquery satisfy the condition.
The ALL operator is also used with comparison operators to evaluate if all values returned by the subquery satisfy the condition.

Por favor revisar la aseveración O(n) Pero para una afirmación que cubra todos los casos, la afirmación más fuerte que podemos hacer es que las consultas anidadas mal planteadas se ejecuta en un tiempo O(log_2 n) ​

SELECT new_table_p.date,COUNT(*) AS post_count
FROM (
	SELECT DATE(MIN(fecha_pub)) AS date,YEAR(fecha_pub) AS post_year
    FROM platziblog.posts
    GROUP BY post_year
)AS new_table_p
GROUP BY new_table_p.date
ORDER BY new_table_p.date;

Como en naruto un genjutsu dentro de otro genjutsu.

La instrucción EXPLAIN ANALYZE es una herramienta que permite ver el plan de ejecución del query, puede ayudar a optimizar Querys.

Uso:

EXPLAIN ANALYZE SELECT * FROM tabla;

Respuesta:

+-------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                         |
+-------------------------------------------------------------------------------------------------+
| -> Rows fetched before execution  (cost=0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1)
 |
+-------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

IMPORTANTE Al momento de utilizar Nested queries hay que ser conciente de su uso por que solamente declararlo y ponerlo a funcionar por si solo puede retrasar el proceso de carga del proyecto ademas que su estructura no tiene escalabilidad

Con respecto a las subconsultas, realmente no se produce un CROSS JOIN (Producto cartesiano), internamente el DBMS busca la existencia de subquery’s, de existir, ejecuta la subconsulta más profunda y el optimizador de SQL guarda el resultado en memoria, una única vez para ser utilizados posteriormente.

El siguiente caso es dado que una subquery se ejecute múltiples veces dado que en cada iteración de cada tupla exista una condición que obligue a evaluar los resultados de la subquery (un WHERE de la consulta padre que contenga una variable dentro del subquery).

Como apunte final, el DBA o desarrollador debe buscar y evaluar la solución más óptima dependiendo del caso o de la regla de negocio que se presente.

Referencia:
“SQL The Complete Reference”

Va mi review:

Nested Queries

Son queries anidados, queries que tienen queries, lo que se realiza es un query que se convierte a una tabla o un valor, y se inyecta una entrada con el FROM o en el WHERE del 2ndo query, alimentando al 2ndo query, que es el query padre.

Cuando se anidan queries, se realiza lo que es un producto cartesiano, haciendo la m multiplicación de todos los registros de una tabla contra todos los registros de otra tabla. Volviéndose exponencial.

Una tabla dinámica es una tabla que está en memoria.

SELECT new_table_projection.date, COUNT(*) AS posts_count
FROM (
	SELECT DATE(MIN(fecha_publicacion)) AS date, YEAR(fecha_publicacion) AS post_year
    FROM posts
    GROUP BY post_year
)AS new_table_projection
GROUP BY new_table_projection.date
ORDER BY new_table_projection.date
;

Para obtener la fecha máxima de publicación:

SELECT *
FROM posts
WHERE fecha_publicacion = (
	SELECT MAX(fecha_publicacion)
    from posts
)
;

Un subquery no es más que una sentencia
SELECT
dentro de otra sentencia. Una tabla derivada es un tipo concreto de subquery que se caracteriza porque está dentro del
FROM
del query “padre”.
En un subquery se ejecuta una búsqueda en la base de datos por cada registro del query “padre”
En una tabla derivada se realiza un solo query a la base de datos, almacenándose los resultados en una tabla temporal en memoria. A esta tabla se accede una vez por cada registro del query padre.

  • SELECT, lo que se quiere mostrar.
  • FROM, origen de datos.
  • WHERE, filtros de datos.
  • GROUP BY, para agrupar la información.
  • ORDER BY, Orden en que se presenta la información.
  • HAVING, filtros que requieren los datos agrupados.

los NEsted Querys se ocupan cuando un problema no se puede solucionar solo viendo tu tabla, este puede necesitar un agregado , donde un query alimenta a otro query,
el producto cartesiano es la multiplicacion de todos los registros de la tabla con todos los registros uno a la vez y se vuelve muy pesado de procesar, lo cual lo vuelve ineficiente por que este crece de manera exponencial, los nested queris no son escalables

USE platziblog;

SELECT new_table_projection.date, COUNT(*) AS posts_count
FROM (
    SELECT DATE(MIN(fecha_publicacion)) AS date, YEAR(fecha_publicacion) AS post_year
    FROM posts
    GROUP BY post_year
) AS new_table_projection
GROUP BY new_table_projection.date 
ORDER BY new_table_projection.date;

SELECT *
FROM posts
WHERE fecha_publicacion = (
	SELECT MAX(fecha_publicacion)
	FROM posts
);

SELECT MAX(fecha_publicacion)
FROM posts;

Son muy prácticas, pero tienen alto consumo de recursos.

¿Cual es la diferencia de utilizar un “with” y un nested querie?

Alguien me podria explicar, en el primer ejemplo (minuto 09:28), que hace el query interior? Es decir el que es:
- SELECT DATE(MIN(fecha_publicacion)) AS…
- FROM posts
- GROUP BY post_year
Es decir, que tabla devolveria eso?

Creo que el curso de prog basica cae como anillo al dedo para relacionar estas busquedas como si fueran codigo en JS, espero mas adelante nos muestre como exportar esta base de datos y hacer las busquedas de manera mas grafica. drop down menus y eso

Excelente clase, desconocia el concepto

anidación de queries!!! 😲

En todas las clases de DB primera vez que escucho el concepto, ya lo habia estudiado por mi cuenta no sabia que tenia ese nombre, que bueno tenerlo presente.

  • Problema principal de los Nested queries: que se haga muy pesado. Esto puede hacerlo difícil de procesar para el DBMS.

Query hell!

ahora si me perdi…

Para Marzo 2023, si te da error asi se soluciona:

Select new_table_projection.date, COUNT(*) as posts_count
from(
select date(min(fecha_publicacion)) AS date, year(fecha_publicacion) AS post_year
from posts
group by post_year
)AS new_table_projection
GROUP BY new_table_projection.date;

Gran aporte los queries anidados

SELECT new_table_projection.date, COUNT(*) AS posts_count
FROM(
SELECT date(MIN(fecha_publicacion) AS date, YEAR(fecha_publicacion) AS post_year
FROM posts
GROUP BY posts_year
) AS new_table_projection
GROUP BY new_table_projection.date
ORDER BY new_table_projection.date;

este tema de los querys anidados me pareció un poco difícil de entender pero creo que al final lo termine comprendiendo

Nested queries / consultas anidadas


Se ocupan cuando tenemos un problema que no podemos solucionar simplemente consultando nuestras tablas, necesitamos una agregación o algún tipo de operación que viene de nuestra u otra tabla, con codiciones separadas.

Hacemos un query, el cual lo convertimos en una tabla o un valor para lluego ser la entrada ( from ) de otro query

select new_table_projection.date , count(*) as posts_count
from (
select date(min(fecha_publicacion)) as date, year(fecha_publicacion) as post_year
from posts
group by post_year
) as new_table_projection
group by new_table_projection.date
order by new_table_projection.date;
;
SELECT *
FROM posts
WHERE fecha_publicacion = (
	SELECT MAX(fecha_publicacion)
    FROM posts
    );

Select field1, field2, …, into NewTable from OldTable Where …,
con el into creamos una nueva tabla con los datos generados por la consulta Select

Otra forma de hacer eso es usar una tabla temporal

WITH TEMPORAL_TABLE 
AS (
SELECT A,B,C,D FROM TABLA1
 )
SELECT * FROM TEMPORAL_TABLE;

Lo que hace esto es crear una tabla en memoria y de esa tabla podemos hacer otra consulta que dependa de la tabla creada anteriormente, podemos crear mas de una tabla temporal.

Aunque es bastante extenso este curso, es fundamental entender las bases de cada proceso de aprendizaje para evitar dolores de cabeza y facilitar el manejo practico de las herramientas que manejaremos en nuestro día a día. Solo formando las bases de forma correcta podremos construir esa infraestructura capaz de superar cualquier situación. Gracias Israel

Este tipo de querys, nos sirven mucho a la hora de hacer actualizaciones masivas, sin miedo a cometer errores

Ejemplo:

SELECT projection.post_month AS Month, 
AVG(post_count) AS "Average Posts"
FROM (
	SELECT YEAR(fecha_publicacion) AS post_year, MONTHNAME(fecha_publicacion) AS post_month, MONTH(fecha_publicacion) AS month_num, 
COUNT(*) AS post_count
   FROM posts
	GROUP BY post_year, post_month
) AS projection
GROUP BY Month
ORDER BY projection.month_num

Esta query devuelve el numero de posts promedio por mes a partir de una query que devuelve el numero de posts por año por mes.

Muy interesante tema esto de los nested queries, aunque no es muy recomendado, como se dice en la clase, pero sienteo que desarrolla nuestra lógica en proporcion de su complejidad

Las conocía como subconsultas

El último ejemplo es muy similar a como hago queries en R usando tidyverse y por medio de la función filter 😃.

Los Nested Queries son poderosos en cuanto a consultas mas estructuradas pero con un nivel de complejidad un poco mayor

Siempre se me había dificultado entender el funcionamiento al nested queries, pero con la explicación me quedo claro

  • Los queries anidados pueden ser tan profundos como se quiera.
  • Se usan comúnmente cuando se tiene un problema en el cual, se necesita agregar una operación de otra tabla o la misma tabla.
  • Haciendo un queri y después que ese se alimente de otro queri.
    Se debe hacer con cuidado ya que cuando se maneja una base de datos bastante robusta generá que el queri se haga muy pesado y no escale, creciendo de forma exponencial, generando que el proceso sea muy pesado para la máquina.