Teoría BBDD

Masterclass Niveles de Aislamiento en SQL Server

Como ya os anuncié la semana pasada, la madrugada del pasado jueves 23 (hora española) tuvo lugar el evento Noches de DBAs en el que, invitado por Alberto de Rossi, pude dar una masterclass sobre niveles de aislamiento en SQL Server para la comunidad Power BI User Group de Lima. Por suerte para todos, esta masterclass está grabada y publicada abiertamente en YouTube. A continuación os comparto la grabación y las diapositivas que vimos en la sesión.

Como sabéis, los niveles de aislamiento y los bloqueos son uno de los temas que más hemos tratado en el blog por lo que a continuación os voy a dejar varios de los artículos en los que podéis profundizar para encontrar más información sobre el tema:

Espero que os haya gustado esta sesión, y que sea la primera de muchas. Dejad vuestro me gusta y comentario para que desde la comunidad nos tengan en cuenta. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, Videos, 0 comentarios

¿Qué son las bases de datos NoSQL?

Recientemente vi un vídeo corto en TikTok en el que el creador del lenguaje SQL se hacía eco de las novedades de las bases de datos NoSQL y, al contrario de lo que podéis estar pensando, alababa sus bondades. 

Menos mal que habló de bases de datos NoSQL porque si llega a decir algo parecido sobre Excel yo pierdo la fe en esto que hacemos y me convierto en monje de clausura con voto de silencio de por vida.

Pero, no perdamos el foco, la verdad es que el paradigma en cuanto a consumo de información está cambiando y esto nos está llevando a un escenario en el que nos encontramos constantemente con nuevos desafíos y oportunidades. Uno de estos desafíos es que cada vez es más común encontrarnos con entornos en los que las restricciones de una base de datos relacional limitarían su usabilidad. De ahí ha surgido una gran oportunidad y no es otra que el surgimiento de las bases de datos NoSQL. Pero, ¿qué son exactamente las bases de datos NoSQL y por qué son importantes?

¿Qué son las bases de datos NoSQL?

Debemos leer NoSQL como Not Only SQL o “No Solo SQL” en español, son un tipo de sistema de gestión de bases de datos que permite el almacenamiento y la recuperación de datos que se modelan de formas distintas a las tabulares utilizadas en las bases de datos relacionales. Estas bases de datos surgieron en respuesta a las limitaciones de las bases de datos SQL tradicionales, especialmente para manejar grandes cantidades de datos distribuidos o para trabajar con archivos de distinto formato en la era del contenido multimedia.

Características de las bases de datos NoSQL

Las bases de datos NoSQL tienen varias características que las distinguen de las bases de datos SQL tradicionales. Algunas de estas características incluyen:

  • Escalabilidad horizontal: Las bases de datos NoSQL están diseñadas para expandirse fácilmente a través de múltiples servidores sin interrupciones de servicio. Esto las hace ideales para aplicaciones con grandes volúmenes de datos y muchas operaciones de lectura y escritura.
  • Flexibilidad de esquemas: A diferencia de las bases de datos SQL, que requieren que defina un esquema antes de insertar datos, las bases de datos NoSQL suelen ser “sin esquema”. Esto significa que puede insertar datos sin definir primero qué tipo de datos va a insertar.
  • Alta disponibilidad: Las bases de datos NoSQL utilizan una variedad de técnicas para garantizar la redundancia y la distribución de los datos, lo que las hace muy resistentes a los fallos y asegura que los datos estén siempre disponibles cuando se necesiten.

Bases de datos distribuidas

Las bases de datos distribuidas son sistemas en los que los datos no están todos almacenados en un solo lugar, sino que están repartidos por varios servidores, a menudo en diferentes ubicaciones físicas. Este tipo de bases de datos son comunes en las bases de datos NoSQL.

La distribución de los datos tiene varias ventajas, como la escalabilidad (puedes añadir más servidores para manejar más datos) y la disponibilidad (si un servidor falla, los datos todavía están disponibles en otros servidores). Sin embargo, también presenta desafíos, como la necesidad de manejar la consistencia de los datos entre los servidores y la gestión de altas latencias cuando las ubicaciones de los servidores están muy separadas entre sí.

Tipos de bases de datos NoSQL

Existen varios tipos de bases de datos NoSQL, cada una con sus propias características y ventajas. Algunos de los tipos más comunes incluyen:

  • Bases de datos clave-valor: Estas bases de datos almacenan datos como un conjunto de pares clave-valor. Son altamente escalables y se utilizan en sistemas de almacenamiento en caché, sesiones de usuario y más.
  • Bases de datos de documentos: Estas bases de datos almacenan datos en documentos, normalmente en formato JSON. Son flexibles y se utilizan en aplicaciones de contenido, catálogos y más.
  • Bases de datos de columnas: Estas bases de datos organizan los datos por columnas en lugar de filas. Son eficientes y se utilizan en análisis de datos, sistemas de recomendación y más.
  • Bases de datos de grafos: Estas bases de datos utilizan estructuras de grafo para representar y almacenar datos. Son útiles para trabajar con datos interconectados, como redes sociales, sistemas de recomendación y más.

SQL-Like en bases de datos NoSQL

Aunque las bases de datos NoSQL se alejan del modelo relacional y del lenguaje SQL, algunas de ellas ofrecen interfaces de consulta que son similares a SQL, a menudo denominadas “SQL-Like”. Estas interfaces permiten a los desarrolladores que están familiarizados con SQL trabajar con bases de datos NoSQL con una curva de aprendizaje más suave.

Por ejemplo, Cassandra ofrece un lenguaje de consulta llamado CQL (Cassandra Query Language) que es muy similar a SQL. Permite a los usuarios realizar consultas de selección, inserción, actualización y eliminación de manera similar a como lo harían en una base de datos SQL.

MongoDB y otras soluciones NoSQL

MongoDB es una base de datos de documentos NoSQL muy popular. Almacena los datos en un formato similar a JSON llamado BSON, que permite una gran flexibilidad en la estructura de los datos. MongoDB es conocido por su escalabilidad horizontal y su rendimiento en aplicaciones con grandes volúmenes de datos.

Otra solución NoSQL popular es Redis, una base de datos en memoria que se utiliza principalmente como sistema de almacenamiento en caché. Redis almacena los datos en estructuras de datos simples como cadenas, listas, conjuntos, conjuntos ordenados con consultas de rango, mapas, HyperLogLogs, índices de bits y flujos.

Conclusión

Las bases de datos NoSQL ofrecen una serie de ventajas sobre las bases de datos SQL tradicionales, incluyendo flexibilidad, escalabilidad y alta disponibilidad. Aunque no son la solución adecuada para todas las situaciones, en los casos correctos pueden proporcionar un rendimiento y una eficiencia significativamente mejores. Como siempre, la elección de la tecnología adecuada depende de las necesidades específicas de su aplicación y su equipo.

En resumen, las bases de datos NoSQL ofrecen soluciones poderosas para manejar los desafíos de los grandes volúmenes de datos y las altas tasas de lectura y escritura. Aunque no son adecuadas para todas las situaciones, pueden ser una excelente opción para ciertas aplicaciones. Como siempre, la elección de la tecnología adecuada depende de las necesidades específicas de nuestra aplicación y el equipo de trabajo.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Otros, 0 comentarios

¿Por qué NO debes USAR NoLOCK en tus consultas SQL?

En ocasiones podemos pensar en un nivel de aislamiento read uncommitted o en el uso de la clausula NoLOCK como la solución a nuestros problemas de bloqueos. Si a ti también te ha pasado este video es para ti. Vamos a ver como su uso tiene muchos riegos y hay resultados inesperados que, para mi, hacen que no sea la mejor de la soluciones.

Espero que te haya gustado esta demostración rápida de los problemas a los que nos podemos enfrentar por usar NoLOCK. Ahora que ya conoces los riegos te recomiendo valorar una solución como Read Committed Snapshot para tus transacciones. Si quieres saber más de niveles de aislamiento te recomiendo nuestros post sobre niveles de aislamiento, niveles de aislaminto – casos prácticos y el uso de nolock.

Banner-Telegram

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, Videos, 0 comentarios

Estimación de Cardinalidad en SQL Server

Como DBAs siempre nos encontramos en una constante búsqueda de optimización y mejora del rendimiento de nuestras bases de datos. Esto, antes o después nos lleva a encontrarnos con  un concepto fundamental pero que puede resultar complicado al principio: la estimación de cardinalidad. Este concepto, aunque pueda parecer magia interna de SQL Server, es esencial para entender cómo el motor de base de datos de SQL Server decide el mejor plan de ejecución para ejecutar nuestras consultas. Es decir, es la clave para elegir el camino más óptimo para resolver lo que le hemos pedido.

Estimación de Cardinalidad

Como hemos adelantado ya en la introducción ,la estimación de cardinalidad es el proceso mediante el cual SQL Server trata de predecir el número de filas a las que va a afectar una consulta. No sólo calcula el número total de filas afectadas sino que lo hace con una granularidad total, calculando cuántas filas pasarán por todos y cada uno de los distintos componentes de los planes de ejecución posibles para resolver la consulta. Este número, también conocido como cardinalidad, es crucial para el optimizador de consultas, ya que sin esta información el motor de base de datos no podría elegir el plan de ejecución más eficiente. SQL Server utiliza estadísticas para realizar estas estimaciones de cardinalidad. 

Estadísticas en SQL Server: La base de la cardinalidad

Como acabamos de ver, el optimizador de consultas utiliza las estadísticas para estimar la cardinalidad. Por ejemplo, si estamos buscando registros de en una tabla donde la columna ‘edad’ es mayor que 30, SQL Server utilizará las estadísticas para estimar cuántos registros cumplen con este criterio. Pero, ¿cómo funciona exactamente?

Las estadísticas en SQL Server son objetos que almacenan información sobre la distribución de los valores en una o más columnas de una tabla o vista indexada. Cada objeto de estadísticas está compuesto por un histograma que describe la distribución de los valores, y un vector de densidad que contiene información sobre la correlación de los valores en las columnas.

SQL Server crea y actualiza automáticamente las estadísticas para las columnas indexadas en nuestras tablas y vistas. También podemos crear estadísticas para columnas no indexadas utilizando el comando CREATE STATISTICS, o podemos actualizar las estadísticas existentes utilizando el comando UPDATE STATISTICS.

Es importante tener en cuenta que las estadísticas pueden volverse obsoletas a medida que los datos en nuestras tablas cambian. Cuando esto sucede, las estimaciones de cardinalidad basadas en estas estadísticas pueden ser inexactas.  Esto puede llevar a SQL Server a elegir un plan de ejecución subóptimo, lo que puede resultar en un rendimiento deficiente de la consulta. Otro de los problemas comunes, aunque el plan de ejecución sea el correcto es una asignación de recursos no óptima para la resolución de las consultas lo que puede llevarnos a una profunda degradación de rendimiento.

Planes de Ejecución: El resultado de la estimación de cardinalidad

Un plan de ejecución es, en resumen, una serie de pasos que SQL Server sigue para ejecutar una consulta. Cada paso en el plan de ejecución tiene su propio componente que representa una operación atómica, como un escaneo de tabla, un join, o una operación de ordenación.

El optimizador de consultas de SQL Server utiliza las estadísticas para estimar la cardinalidad y elige el plan de ejecución que tiene el menor costo estimado. El costo de un plan de ejecución se mide en términos de la cantidad de recursos que se espera que consuma, como la CPU, la E/S de disco, y la memoria RAM.

Podemos ver el plan de ejecución de una consulta utilizando la opción SET SHOWPLAN_ALL ON. Esto nos proporcionará una representación gráfica del plan de ejecución, junto con información detallada sobre cada operación en el plan.

No vamos a profundizar mucho más en este sentido pues ya le hemos dedicado a este tema este artículo completo en este blog.

Conclusión

La estimación de cardinalidad es un aspecto esencial en la optimización de consultas en SQL Server. Aunque puede parecer un concepto complejo, entender cómo funciona puede ayudarnos a mejorar significativamente el rendimiento de nuestras bases de datos.

Es importante recordar que las estadísticas, que son la base de la estimación de cardinalidad, deben mantenerse actualizadas para garantizar estimaciones precisas. Como siempre, la clave está en conocer nuestras bases de datos, entender cómo se utilizan y aplicar este conocimiento para optimizar su rendimiento.

En resumen, la estimación de cardinalidad es una herramienta poderosa en nuestras manos. Con un buen entendimiento de cómo funciona, podemos hacer que nuestras bases de datos trabajen de manera más eficiente y efectiva. ¡Sigamos aprendiendo y mejorando juntos!

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 0 comentarios

Agenda semanal SoyDBA

Iniciamos una nueva semana con una agenda apasionante, esta semana va a ser muy especial para mí y todo es gracias a vosotros que día a día me apoyáis leyendo y compartiendo mi contenido. Creo que, gracias a vuestro constante apoyo y entusiasmo por aprender cosas nuevas, se está formando una gran comunidad de profesionales alrededor de este blog. Personalmente os estoy profundamente agradecido ya que este apoyo repercute directamente en mi crecimiento personal y desarrollo profesional. ¡GRACIAS POR ACOMPAÑARME EN ESTE MARAVILLOSO PROYECTO!

Ahora, sin más palabrería cursi, me gustaría compartir con vosotros la emocionante agenda de actividades que se nos presenta esta semana esperando que podáis vosotros también participar de ella

Noches de DBAs: primer hito en mi agenda semanal

Como primera actividad de esta semana estaré participando como ponente en el evento Noches de DBAs. Este evento es organizado por Alberto de Rossi para la comunidad de Power BI User Group de Lima en Perú. Es una gran oportunidad para aprender, compartir conocimientos y experiencias con otros profesionales del campo. Nos vamos a enfocar en el lado de la fuente de datos cuando usamos la plataforma de datos Microsoft. Conocer sobre la operación de las fuentes y cómo optimizarlas también es importante para mantener adecuadamente una solución de inteligencia de negocios con Power BI. En esa noche podréis asistir a dos presentaciones a cargo de experimentados DBA. Trataremos los siguientes temas:

  • Niveles de aislamiento en SQL Server y gestión de la concurrencia de los procesos, a cargo de Roberto Carrancio. 
  • Cómo capturar y optimizar los querys ejecutados desde Power BI, a cargo de Alberto De Rossi

Ponentes:

Alberto De Rossi

Alberto es un profesional con más de 20 años de experiencia en tecnologías de la información, dedicado a la consultoría de proyectos relacionados con el diseño, implementación y administración de soluciones de datos e inteligencia de negocios, así como a la capacitación en Azure, Power BI y SQL Server. Cuenta en su haber con el reconocimiento MVP de Microsoft desde hace ya 6 años. Os dejo por aquí su perfil de MVP.

Roberto Carrancio

Roberto, el mismo que escribe estas líneas (y el resto del blog). Como ya sabéis soy DBA de SQL server con más de 10 años de experiencia en el sector. Durante este tiempo he tenido oportunidad de lidiar con proyectos en compañías de todos los tamaños y sectores, desde pymes hasta grandes multinacionales. 

Agenda

Este evento tendrá lugar el Miércoles 22 de Mayo a las 18:30 hora de Perú (GMT-5), lo que en España es el Jueves 23 de Mayo a las 01:30. El evento será online, retransmitido en directo y la asistencia es gratuita, simplemente tenéis que apuntaros aquí para recibir el enlace con la invitación. Una vez concluidas las sesiones, quedarán disponibles abiertamente para su consulta en el canal de Youtube de Power BI User Group Lima. Os dejaré los enlaces en mis redes y posiblemente también en el blog.

Power Platform Madrid 2024 para cerrar la agenda semanal

Después de mi participación en el evento de Lima, asistiré presencialmente al evento Power Platform Madrid 2024 el sábado 25 por la mañana. En esta ocasión, estaré asistiendo como oyente, buscando aprender de otros expertos de la comunidad y mantenerme al día con las últimas tendencias y desarrollos en el sector. Os dejo la descripción del evento en el que podréis encontrar talleres prácticos el viernes 24 y más de 40 ponencias el sábado 25:

Bienvenido a la sesión presencial de Power Platform de Madrid 2024, el evento para profesionales y entusiastas de la tecnología, centrado en la potente herramienta que es Microsoft Power Platform.

Este evento representa una oportunidad única para aquellos que buscan conectar con otros miembros de la comunidad, compartir desafíos y soluciones, y expandir su red de contactos profesionales en un ambiente de colaboración y descubrimiento.

Ya sea que te estés iniciando en estas tecnologías o busques afianzar y expandir tu maestría, este evento está diseñado para inspirar y elevar tus capacidades.

El viernes 24 se celebrarán talleres prácticos dirigidos por grandes profesionales, y el sábado 25 sesiones divulgativas con todo un elenco de ponentes. Puedes consultar todos los detalles en la agenda del evento ¡No te lo pierdas!

Consulta aquí la agenda de talleres y sesiones

Compra aquí tu entrada.

Espero que esta semana llena de nuevas experiencias y aprendizajes para mi os resulte interesante también a vosotros. Me encantaría veros por ahí. Y, por supuesto, estaré aquí para compartir con vosotros todas las novedades y conocimientos adquiridos durante estos eventos. Para terminar, no os preocupéis, el blog va a seguir su programación habitual con artículos y video blogs. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Otros, 0 comentarios

¿Cómo no hacer un DWH? (Parte 1 de 2)

Hoy vamos a viajar al pasado para recuperar un artículo de Ralph Kimball escrito en 2001 pero que aún, 23 años después, sigue estando muy presente. El artículo recoge los 12 errores más comunes (y más perjudiciales) que se cometen a la hora de diseñar un DataWareHouse (DWH). Si ya tienes experiencia en este tipo de entornos vas a notar que son errores que a menudo podemos cometer pero que necesariamente tenemos que corregir al poco tiempo. En estos entornos no valen las cosas a medias, para un buen rendimiento es necesario hacer las cosas bien desde el principio o la bola crecerá tanto que será ingestionable.

¿Qué es un DWH?

Empecemos por el principio, un almacén de datos, datawarehouse o DWH es un sistema diseñado para almacenar y, posteriormente, analizar datos. No es un sistema cualquiera y tiene sus particularidades ya que en él, vamos a integrar todos los datos de los distintos orígenes de nuestra organización, incluso de orígenes externos. Por ejemplo, en nuestro DWH tendremos los datos de nuestra aplicación de ventas, contabilidad, tienda web y, en ocasiones, incluso la base de datos de artículos de nuestros proveedores.

Banner-Telegram

Los DWH se caracterizan por contener grandes cantidades de información histórica permitiendo a los analistas de datos realizar análisis temporales y crear predicciones de tendencias a futuro. Como podrás imaginar, para que todo esto funcione, tiene que estar todo muy organizado, estructurado y optimizado para el acceso y análisis rápido de la información. Gracias a procesos ETL (extracción, transformación y carga por sus siglas en inglés) vamos a cargar las tablas de dimensiones y de hechos del modelo de estrella de nuestro DWH,

Errores comunes cuando creamos un DWH

Ahora si, después de esta pequeña introducción vamos al lío, estos son los doce errores más comunes definidos por Kimball.

Error 12: Incluir campos de texto en tablas de hechos para filtrar u ordenar

En un modelo dimensional, las tablas de hecho y de dimensiones se diferencian por contener indicadores numéricos y atributos respectivamente. A veces, la clasificación de un dato puede ser ambigua, como la hora de una venta o el nombre del transportista que nos entrega un pedido. En caso de duda, os recomiendo evitar textos largos en las tablas de hecho para optimizar el espacio y el rendimiento, y considerar como dimensión cualquier dato compartido entre varias tablas de hecho. Al fin y al cabo el almacenamiento es barato en precio pero costoso a la hora de leerlo, las tablas de hechos pueden llegar a tener millones de registros y debemos evitar poner en ellas cualquier texto que pueda ser común a varias tablas o registros. Eso será siempre una dimensión.

Error 11: Escatimar en la información de nuestras dimensiones para ahorrar espacio.

La información es poder y aunque en este momento podamos pensar que no necesitamos ciertos datos y que podemos prescindir de ellos siempre es importante guardarlos por si en un futuro los necesitamos. Esa es la idea detrás de las primeras capas bronce de los data lakes pero, llevado al caso que nos ocupa, en nuestro DWH es una buena idea almacenar esa información si se refiere a dimensiones. El tamaño de las tablas de dimensiones con cientos o pocos miles de registros será despreciable al lado de las grandes tablas de hechos con millones de registros por lo que no debemos preocuparnos por ese aspecto. Otra cosa será que saquemos los datos en la capa de presentación si no se nos solicita pero tenerlo siempre será una buena idea.

Error 10: Dividir las jerarquías y en varias dimensiones

Las dimensiones se agrupan en jerarquías que tienen una relación de uno a muchos. En un país existen muchas provincias y en cada una de esas provincias muchas poblaciones. Cada población a su vez tiene muchos clientes. Podemos pensar en que es una buena idea tener las tablas normalizadas como nos enseñaron en la universidad y crear una tabla por cada una de esas dimensiones.

Eso es lo idea para un modelo transaccional pero cuando hablamos de un DWH donde las lecturas priman sobre las escrituras y el almacenamiento, en la última capa de nuestro DWH el modelo debe ser puramente de estrella y no de copo de nieve por lo que en una sola tabla para esa jerarquía. Es importante aquí destacar de esta última frase la referencia a esa última capa que consumen los reportes ya que nuestro DWH tendrá otras capas inferiores donde sí tendremos normalizados los datos.

Error 9: No enfrentar las dimensiones lentamente cambiantes

Ya explicamos en nuestro artículo sobre el modelo de estrella lo que es una dimensión de variación lenta o lentamente cambiante. Es importante que anticipemos estos cambios desde el inicio del diseño de nuestro modelo o en un futuro tendremos problemas. Por ejemplo, no os imagináis el caos que se me montó una vez a mi cuando un NIE de un cliente extranjero cambió a DNI al obtener la nacionalidad y yo no había pensado que ese dato era cambiante. 

Error 8: No crear foreign keys específicas en tu DWH

En ocasiones podemos pensar que un valor intrínseco de nuestras dimensiones puede actuar como clave y cometemos el error de no crear una clave dedicada para esos registros. Sin embargo, a la larga eso puede llegar a ser un problema y para evitarlo es aconsejable crear nuestros propios identificadores numéricos para los registros de nuestras dimensiones y enlazar con ellos las tablas de hechos. Pensad en el ejemplo del error anterior, el NIE o DNI puede parecer un identificador personal válido pero cuando no lo es puede ser un verdadero quebradero de cabeza. 

Error 7: Añadir dimensiones a la tabla de hechos del DWH

Esto puede parecer básico, pero si ya os habéis enfrentado a varios modelos de DWH sabréis que es más común de lo que parece. En un modelo de estrella todas las dimensiones deben estar en sus tablas de dimensiones y las tablas de hechos solo deben tener relación con esas dimensiones o jerarquía. Caer en este error nos llevará a un mayor tamaño de nuestra tabla de hechos lo que repercutirá directamente en el consumo de E/S de nuestras consultas y empeorará el rendimiento.  

Conclusión

Hemos visto la mitad de los errores más comunes descritos por Kimball, como el artículo si no iba a quedar muy grande vamos a dejar los 6 siguientes errores (y los más graves) para una segunda parte. Espero que os esté gustando, que os sea de utilidad y por supuesto que a partir de ahora no caigáis en estos errores. Si al leer esto has pensado en algo que tienes mal en tu DWH solucionalo antes de que sea tarde, vas a ver que, a la larga, la ganancia es sustancial. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, 1 comentario

JOIN: La guía definitiva

¿Sabes qué son y cuándo usar cada tipo de JOIN? Esta es la base de cualquier consulta SQL que empieza a volverse compleja. Seguro que a ninguno os sorprende que os diga que, hoy en día, el conocimiento de SQL es una de las habilidades más demandadas en el mercado laboral. Cualquiera que trabaje con datos, a casi cualquier nivel, va a necesitar en algún momento consultar información y en este aspecto el lenguaje SQL es clave. No solo lo usan todas las bases de datos relacionales, sino que hasta las bases de datos NoSQL o descentralizadas han terminado admitiendo este lenguaje de consultas. O, al menos, un  lenguaje “SQL Like” para la consulta de sus datos no estructurados o semiestructurados.

Por todo esto, se hace muy importante para los profesionales de datos tener la capacidad de escribir consultas complejas con cláusulas JOIN que nos permitan unir la información de varias tablas. 

Joins en SQL

Los joins en SQL son la base de cualquier consulta compleja. Como su propio nombre indica, nos permiten combinar filas de dos o más tablas basándonos en una columna relacionada entre ellas. Suele ser una Foreing Key pero realmente no es necesario que exista esa restricción entre las tablas para hacer la consulta con un join. 

Banner-Telegram

Tipos de Join

Como hemos podido ver, los joins son una de las cláusulas más importantes que podemos usar en nuestra consulta de SQL. Además existen varios tipos de joins y cada uno de ellos tiene una función y un uso específico.

INNER JOIN

El INNER JOIN es la operación más básica. Algunos SGBD como SQL Server o Azure SQL admiten la sintaxis JOIN a secas sin especificar el INNER. Con este join seleccionaremos registros que tienen valores coincidentes en ambas tablas. Es el más común de los joins y se utiliza con frecuencia para combinar filas de dos o más tablas.

LEFT (OUTER) JOIN

El LEFT JOIN nos devuelve todos los registros de la tabla izquierda y los registros coincidentes de la tabla derecha. Si no hay una coincidencia, el resultado es NULL en el lado derecho.

RIGHT (OUTER) JOIN

El RIGHT JOIN nos va a devolver todos los registros de la tabla derecha y los registros coincidentes de la tabla izquierda. Si no hay una coincidencia, el resultado es NULL en el lado izquierdo.

FULL (OUTER) JOIN

El FULL JOIN devuelve todos los registros cuando hay una coincidencia en cualquiera de las tablas izquierda o derecha. Si no hay una coincidencia, el resultado es NULL en ambos lados.

Usos avanzados de JOINS

Además de los usos básicos de JOIN que ya hemos visto, podemos combinarlos con el uso del filtro IS NULL para obtener otro tipo de datos. Por ejemplo combinando LEFT JOIN 

con un filtro ISNULL cuando la clave de la tabla derecha es nulo podremos sacar solo los registros de una tabla que no tienen relaciones con otra. Igual pero al revés podemos hacerlo con RIGHT JOIN. Combinando un FULL JOIN con un filtro que nos garantice que las claves por las que enlazamos son nulas podremos sacar los registros de ambas tablas que no tienen relación con la otra.

Se que todo esto os puede parecer un poco lioso así contado pero seguro que con esta infografía lo vais a ver más claro. Ya sabéis, una imagen vale más que mil palabras (600 a estas alturas del artículo 🤣 ).

join

Escrituras con JOINS

Esto no sería la guía definitiva de los joins si no mencionamos también la sintaxis de las operaciones de escritura. Obviamente no tiene sentido unir varias tablas en una consulta de inserción ya que los insert son en una sola tabla pero sí que podremos querer actualizar o borrar datos de una tabla cruzando con otras para asignar un valor presente en otra tabla o para alguna validación extra. 

Update con JOIN

Es un escenario bastante común, en ocasiones queremos actualizar un valor de una tabla tal como lo tenemos en otra. Para eso podemos hacer un update con join tal como vemos aquí.

Como veis en este caso, tenemos una tabla de backup y queremos restaurar el valor de CustomerID desde el backup. Este es uno de los usos más comunes de este tipo de sintaxis.

Delete con JOIN

Existen varios escenarios en los que vamos a necesitar un join en una clausula delete. El más sencillo será borrar los registros de una tabla que tengan coincidencia en otra tabla. Sin embargo también podemos, por ejemplo, querer borrar solo los registros que no existen en la segunda tabla. Vamos a ver estos y otro ejemplo extra

Ejemplo sencillo de borrado de registros de una tabla origen que tengan coincidencia en una tabla filtro. En este caso vamos a borrar todos los pedidos de clientes con una nacionalidad en concreto:

Otro ejemplo muy común como ya hemos visto es el de borrar datos de una tabla que no tengan relaciones con otras. Por ejemplo, queremos borrar todas las líneas de una factura que no tengan cabecera.

Por último, para cerrar ya esta guía vamos a ver un ejemplo especial que no todos los sistemas de bases de datos admiten que es el uso de join para borrados en cascada. Esta sintaxis, no la vais a poder usar en SQL Server o Azure SQL pero si, por ejemplo, en MySQL.

Conclusión

Los joins son una herramienta esencial en SQL que nos permite combinar datos de diferentes tablas de manera eficiente. Aunque puede parecer complicado al principio, con práctica y experiencia, se convertirán en una parte integral de tus consultas SQL. No en vano son imprescindibles para todo DBA o trabajador de datos. Recuerda, la mejor manera de aprender es practicando, usa tus datos de demo para hacer pruebas e interiorizar los conceptos. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios