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

1

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

Introducción a las bases de datos relacionales

2

Historia de las bases de datos relacionales

3

Entidades y atributos

4

Entidades de Platzi Blog

5

Relaciones

6

Múltiples muchos

7

Diagrama ER

8

Diagrama Físico: tipos de datos y constraints

9

Diagrama Físico: normalización

10

Formas normales en Bases de Datos relacionales

11

Diagrama Físico: normalizando Platziblog

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

12

¿Qué es RDB y RDBMS?

13

Instalación local de un RDBMS (Windows)

14

Instalación local de un RDBMS (Mac)

15

Instalación local de un RDBMS (Ubuntu)

16

Clientes gráficos

17

Servicios administrados

SQL hasta en la sopa

18

Historia de SQL

19

DDL create

20

CREATE VIEW y DDL ALTER

21

DDL drop

22

DML

23

¿Qué tan standard es SQL?

24

Creando Platziblog: tablas independientes

25

Creando Platziblog: tablas dependientes

26

Creando Platziblog: tablas transitivas

Consultas a una base de datos

27

¿Por qué las consultas son tan importantes?

28

Estructura básica de un Query

29

SELECT

30

FROM

31

Utilizando la sentencia FROM

32

WHERE

33

Utilizando la sentencia WHERE nulo y no nulo

34

GROUP BY

35

ORDER BY y HAVING

36

El interminable agujero de conejo (Nested queries)

37

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

38

Preguntándole a la base de datos

39

Consultando PlatziBlog

Introducción a la bases de datos NO relacionales

40

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

41

Servicios administrados y jerarquía de datos

Manejo de modelos de datos en bases de datos no relacionales

42

Top level collection con Firebase

43

Creando y borrando documentos en Firestore

44

Colecciones vs subcolecciones

45

Recreando Platziblog

46

Construyendo Platziblog en Firestore

47

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

48

Bases de datos en la vida real

49

Big Data

50

Data warehouse

51

Data mining

52

ETL

53

Business intelligence

54

Machine Learning

55

Data Science

56

¿Por qué aprender bases de datos hoy?

Bonus

57

Bases de datos relacionales vs no relacionales

58

Elegir una base de datos

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

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 141

Preguntas 21

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta 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

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

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.

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.

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

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

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:

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

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.

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.

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.

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

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.

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

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

excelente!!!

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

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!

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

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

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
)

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.

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

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

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

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;

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

SELECT * 
FROM posts 
ORDER BY fecha_publicacion DESC 
LIMIT 1;

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Como en naruto un genjutsu dentro de otro genjutsu.

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

Uso:

EXPLAIN ANALYZE SELECT * FROM tabla;

Respuesta:

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

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

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

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

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

Referencia:
“SQL The Complete Reference”

Va mi review:

Nested Queries

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

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

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

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

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

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

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

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

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

USE platziblog;

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

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

SELECT MAX(fecha_publicacion)
FROM posts;

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

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

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

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

Excelente clase, desconocia el concepto

anidación de queries!!! 😲

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

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

Query hell!

ahora si me perdi…

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

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.

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

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.

SELECT * FROM post
WHERE id_post = (
SELECT max(id_post)
FROM post
);

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.

Ejemplo de subquerys para ver el aguejero de conejo

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.

Recomendación, crear un server y dbs dedicadas a la reporteria para no afectar el rendimiento de server DB de producción por las super querys de reporteria.

No me quedo muy claro por que tenerles cuidado

No conocía este tipo de querys pero no es mejor los IN para hacer los subqueries

Estoy algo confundido, al final generas dos veces GROUP BY new_table_projection.date, el segundo no tendría sentido porque es literalmente lo mismo, o yo lo estoy entendiendo mal?

Ejercicio Query anidado (nested query)

Interesante el poder utilizar un query dentro de otro query

cuando una consulta es muy compleja la BD se vuelve lenta

me recordó a la programación recursiva 😂 😢

No entendí si según la notación Big O es O(n) o O(n exp (n))

Muchas gracias por la introducción a los queries anidados.

También se les conoce como subquery

Muy interesante, hay que tener es cuidado con el rendimiento.

Otra forma que yo he utilizado para hacer consultas son los Stored Procedure, usualmente cuando genero reportes.