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

Instalaci贸n local de un RDBMS (Windows)

14

驴Qu茅 es RDB y RDBMS?

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 178

Preguntas 32

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.

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

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

驴Qu茅 diferencia hay entre una tabla temporal local y una tabla temporal global?

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.

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.

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

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

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, 馃洟鈿欚煋

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.

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

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鈥

no entendi un culo
* 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

Cantidad de posts por categoria:

select categorias.nombre_categoria, count(*) as posts_count
from posts
join categorias on categorias.id = posts.categoria_id
group by categorias.nombre_categoria
order by posts_count desc
;