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 鈥渏ugando鈥 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鈥檚 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鈥檚, 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:
鈥淪QL 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 鈥減adre鈥.
En un subquery se ejecuta una b煤squeda en la base de datos por cada registro del query 鈥減adre鈥
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 鈥渨ith鈥 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.