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

2

Playground: tu primera consulta en bases de datos

Introducción a las bases de datos relacionales

3

Historia de las bases de datos relacionales

4

Qué son entidades y atributos

5

Entidades de Platzi Blog

6

Relaciones

7

Múltiples muchos

8

Diagrama ER

9

Diagrama Físico: tipos de datos y constraints

10

Diagrama Físico: normalización

11

Formas normales en Bases de Datos relacionales

12

Diagrama Físico: normalizando Platziblog

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

13

¿Qué es RDB y RDBMS?

14

Instalación local de un RDBMS (Windows)

15

Instalación local de un RDBMS (Mac)

16

Instalación local de un RDBMS (Ubuntu)

17

Clientes gráficos

18

Servicios administrados

SQL hasta en la sopa

19

Historia de SQL

20

DDL create

21

Playground: CREATE TABLE

22

CREATE VIEW y DDL ALTER

23

DDL drop

24

Playground: VIEW, ALTER y DROP en SQL

25

DML

26

Playground: CRUD con SQL

27

¿Qué tan standard es SQL?

28

Creando Platziblog: tablas independientes

29

Creando Platziblog: tablas dependientes

30

Creando Platziblog: tablas transitivas

Consultas a una base de datos

31

¿Por qué las consultas son tan importantes?

32

Estructura básica de un Query

33

SELECT

34

Playground: SELECT en SQL

35

FROM y SQL JOINs

36

Utilizando la sentencia FROM

37

Playground: FROM y LEFT JOIN en SQL

38

WHERE

39

Utilizando la sentencia WHERE nulo y no nulo

40

Playground: Filtrando Datos con WHERE

41

GROUP BY

42

ORDER BY y HAVING

43

Playground: Agrupamiento y Ordenamiento de Datos

44

El interminable agujero de conejo (Nested queries)

45

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

46

Preguntándole a la base de datos

47

Consultando PlatziBlog

48

Playground: Prueba Final con PlatziBlog

Introducción a la bases de datos NO relacionales

49

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

50

Servicios administrados y jerarquía de datos

Manejo de modelos de datos en bases de datos no relacionales

51

Top level collection con Firebase

52

Creando y borrando documentos en Firestore

53

Colecciones vs subcolecciones

54

Recreando Platziblog

55

Construyendo Platziblog en Firestore

56

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

57

Bases de datos en la vida real

58

Big Data

59

Data warehouse

60

Data mining

61

ETL

62

Business intelligence

63

Machine Learning

64

Data Science

65

¿Por qué aprender bases de datos hoy?

Bonus

66

Bases de datos relacionales vs no relacionales

67

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)

44/67
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 179

Preguntas 32

Ordenar por:

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

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.

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.

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.

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

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
);

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

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.

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.

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

SELECT * 
FROM posts 
ORDER BY fecha_publicacion DESC 
LIMIT 1;

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

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.

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.

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

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;

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
)

excelente!!!

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

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.

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.

no entendi un culo

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?

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]”);

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, 🛢⚙📈

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

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

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.

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]");

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 que funcionase la query tuve que hacer una pequeña modificación, añadiendo al final "AS new\_table\_projection" 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;

🪺 Los Nested Queries o consultas anidadas son una herramienta poderosa en SQL que permite realizar consultas dentro de otras consultas. Esta capacidad proporciona una gran flexibilidad y profundidad al analizar datos, realizar operaciones condicionales basadas en los resultados de otras consultas y vincular datos de manera compleja sin necesariamente realizar un JOIN físico entre tablas.

Conceptos Básicos de Nested Queries

  • Subconsultas: Una subconsulta o consulta anidada es una consulta SQL que se inserta dentro de otra consulta SQL. Las subconsultas pueden aparecer en las cláusulas SELECT, FROM, y WHERE.
  • Independencia: Las subconsultas pueden ejecutarse de manera independiente de la consulta externa, pero su resultado es utilizado por la consulta externa.
  • Retorno de Valores: Dependiendo de su ubicación y propósito, una subconsulta puede devolver un único valor, múltiples valores o incluso un conjunto de registros (como una tabla temporal en memoria).

Usos Comunes

  • Filtrado de Datos: Utilizar una subconsulta en la cláusula WHERE para filtrar registros basados en el resultado de otra consulta.

    SELECT * FROM empleados
    WHERE departamento_id IN (SELECT id FROM departamentos WHERE nombre = 'Tecnología');
    
    
  • Selección de Datos: Usar subconsultas en la cláusula SELECT para calcular valores dinámicos basados en los resultados de otra consulta.

    SELECT nombre, (SELECT COUNT(*) FROM ventas WHERE ventas.empleado_id = empleados.id) AS total_ventas
    FROM empleados;
    
    
  • Origen de Datos: Emplear una subconsulta en la cláusula FROM para tratar el resultado de la subconsulta como una tabla temporal sobre la cual se puede realizar otra consulta.

    SELECT tmp.nombre, tmp.total_ventas
    FROM (SELECT empleado_id, COUNT(*) AS total_ventas FROM ventas GROUP BY empleado_id) AS tmp;
    
    

Consideraciones de Rendimiento

Aunque las consultas anidadas ofrecen una gran potencia y flexibilidad, también presentan desafíos:

  • Rendimiento: Pueden ser intensivas en recursos y lentas en ejecución, especialmente si las subconsultas generan grandes conjuntos de datos intermedios o si la profundidad de anidación es muy alta.
  • Complejidad: La legibilidad y mantenimiento de las consultas pueden verse afectados negativamente a medida que aumenta la complejidad de las anidaciones.

Productos Cartesianos

La advertencia sobre el producto cartesiano se aplica principalmente cuando se usa una subconsulta en la cláusula FROM sin un criterio de unión adecuado, lo que puede resultar en que cada fila de una tabla se combine con cada fila de otra tabla, multiplicando exponencialmente el número de filas resultantes.

Mejores Prácticas

  • Limitar la Profundidad: Mantén las consultas lo más simples posible y limita la profundidad de anidación.
  • Optimizar Subconsultas: Asegúrate de que las subconsultas estén bien optimizadas y retornen solo los datos necesarios.
  • Considerar Alternativas: En algunos casos, reestructurar la consulta o utilizar JOINs puede ofrecer un mejor rendimiento que las consultas anidadas.

Las consultas anidadas son una herramienta valiosa en el arsenal de SQL, permitiendo realizar operaciones que de otro modo serían muy difíciles o imposibles de lograr. Sin embargo, es importante utilizarlas con cuidado y consideración por el impacto en el rendimiento y la complejidad del código.

* Existen los queries anidados, que sirven para hacer JOIN de un query con otro query u otra tabla. Se le llama agujero de conejo porque la anidación de queries no tiene límite * Estos queries anidados se usan cuando se tiene un problema que no se puede solucionar con solo consultar la tabla * Los queries anidados no son escalables y por lo tanto hay que saber usarlos, sobre todo en queries que se sabe no que van a estar creciendo constantemente ```js 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; ``` * En la sentencia anterior estamos haciendo un query dentro de otro ```js SELECT * FROM posts WHERE fecha_publicacion = ( SELECT MAX(fecha_publicacion) FROM posts); ``` * En la sentencia anterior solo traemos una fila, que es la última publicación 📌 **RESUMEN: El poder hacer una query dentro de otra query es importante saberlo, solo que no es muy recomendable usarlo todo el tiempo, y menos cuando la BD cambia constantemente**

Cool 🤩🤩🤩

Nested queries, también conocidas como subconsultas o consultas anidadas, son consultas SQL que se incluyen dentro de otras consultas. Estas subconsultas se utilizan para realizar operaciones más complejas y permiten combinar y anidar múltiples niveles de consultas para obtener información más específica o realizar comparaciones detalladas.

-Hay dos tipos principales de subconsultas:

  1. Subconsultas Correlacionadas:

*Una subconsulta correlacionada es aquella en la que la subconsulta depende de los resultados de la consulta externa.
La subconsulta se ejecuta para cada fila devuelta por la consulta principal.
-Se utiliza cuando necesitas comparar cada fila de la consulta principal con los resultados de una subconsulta.
Ejemplo:

SELECT nombre
FROM empleados
WHERE salario > (SELECT AVG(salario) FROM empleados WHERE departamento = 'Ventas');
  1. Subconsultas no Correlacionadas:

Una subconsulta no correlacionada es independiente de la consulta externa y se ejecuta una vez antes de que se ejecute la consulta principal.
Se utiliza cuando la subconsulta no depende de los resultados de la consulta externa.
Ejemplo:

SELECT nombre
FROM empleados
WHERE salario > (SELECT AVG(salario) FROM empleados);

Las subconsultas pueden aparecer en diversas cláusulas de una consulta, como SELECT, FROM, WHERE, HAVING, entre otras, dependiendo de la lógica y los resultados que desees obtener.

En general, el uso de subconsultas permite realizar operaciones más avanzadas y realizar comparaciones más detalladas entre conjuntos de datos. Sin embargo, es importante tener en cuenta la eficiencia y la optimización del rendimiento al utilizar subconsultas, especialmente en conjuntos de datos grandes.

Subconsulta en la cláusula DONDE: Puedes utilizar una subconsulta para filtrar los resultados de la consulta principal. Por ejemplo, puedes buscar todos los clientes que han realizado compras por encima de cierto monto.

SELECT customer_name
FROM customers
WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_total > 1000);

En caso de que quieran practicar y hacer ejercicios de SQL

https://www.w3schools.com/sql/sql_distinct.asp

me echa humo la cabeza