cloud

Importar y exportar de Excel a SQL en vídeo

En este octavo Video Blog vamos a ver de forma práctica una de las entradas del blog www.soydba.es que mejor resultado ha tenido y que más os interesa. La importación de Excel a SQL Server y viceversa. Excel es una de las herramientas para consumo de datos más utilizadas del mundo y en multitud de ocasiones nos veremos en la necesidad tanto de importar datos de Excel a SQL como al revés, de exportar de SQL a Excel. Gracias al asistente de import / export integrado en el SSMS esta tarea será casi como un juego de niños.

El asistente que hemos podido ver en el vídeo es muy versatil y no solo nos va a permitir importar o exportar datos entre SQL y Excel sino que también entre SQL y SQL u otros origenes o destinos como archivos de texto plano, CSV u otras bases de datos (siempre que tengamos los drivers correctos en el equipo).

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, SQL Server, Videos, 0 comentarios

Perform volume maintenance tasks

Muchos me habéis preguntado por el permiso “Perform volume maintenance tasks” o “Realizar tareas de mantenimiento del equipo” por el que pregunta SQL Server al instalarse. Hay quien me ha dicho que siempre lo marca, otros que nunca pero en general existe cierto desconocimiento sobre sus pros y sus contras y lo que es más importante sobre lo que hace o no este permiso de Windows. En el artículo de hoy vamos a tratar de responder estas dudas.

Inicialización de archivos de base de datos

Seguramente te suene este concepto, la inicialización de archivos de base de datos es el proceso por el que SQL Server crea y dimensiona los archivos de bases de datos y logs ya sea de manera manual o con el crecimiento automático. Desde los inicios del SQL moderno que conocemos hoy en día (SQL 2005) esto implica crear o redimensionar los ficheros para reservar ese espacio para la base de datos. Durante este proceso SQL Server pone a 0 todos los sectores del disco duro a nivel físico para posteriormente ir rellenandolos con datos. Esto es un proceso lento y pesado que demora las operaciones de escritura, por eso las buenas prácticas siempre recomiendan tener todos los ficheros dimensionados previamente a la hora de trabajar para evitar el crecimiento automático.

Banner-Telegram

Ahora bien, existe una excepción que nos permitirá saltarnos este paso y dimensionar los ficheros de datos sin tener que modificar los sectores del disco para establecerlos a 0 y es lo que se conoce como inicialización instantánea de base de datos gracias al privilegio “perform volume maintenance task”. Esto también afecta a los archivos de base de datos de Analysis Service. Esta configuración también se aplica en los ficheros de log desde SQL Server 2022 y está disponible también en las bases de datos y en las instancias administradas de Azure. 

Perform volume maintenance tasks

Este permiso, asignado por directiva de windows por defecto a los usuarios administradores del equipo, permite realizar las tareas de mantenimiento típicas sobre los discos duros tales como desfragmentar, crear y modificar nuevos volúmenes o ejecutar el asistente de limpieza. Esto es lo que dice la teoría, pero como hemos visto, a nosotros como DBAs nos interesa porque es lo que nos va a permitir la inicialización instantánea de los archivos de bases de datos.

Consideraciones de seguridad

Como hemos visto, esta política por defecto otorga el permiso a los administradores del equipo, sin embargo, vosotros que sois buenos DBAs, sabréis que no es conveniente que la cuenta de servicio de SQL Server sea administradora local. O eso dicen las buenas prácticas de seguridad. 

Además, ten en cuenta que, gracias a este permiso es posible ver el valor de los sectores de disco y recuperar información eliminada, lo que también puede ser un problema de seguridad. En este sentido, tendremos que valorar junto con el equipo de ciberseguridad de nuestra empresa, la ganancia que vamos a sacar de este privilegio frente a los posibles riesgos de seguridad.

Por un lado, si tenemos bien dimensionados los archivos de datos para nuestro crecimiento y podemos hacer redimensionamiento manuales en ventanas de mantenimiento fuera de las horas de mayor carga de trabajo es probable que no sea necesario. Si esto no es así y tenemos muchos crecimientos automáticos sin, además, tener este privilegio concedido, podremos experimentar grandes caídas del rendimiento e incluso encontrarnos en el log de errores de SQL los errores 5144 y 5145 de timeout al redimensionar los ficheros. En estos casos será recomendable conceder el permiso siempre reduciendo al mínimo los riesgos de seguridad, por ejemplo, usando para SQL Server cuentas de servicio administradas gMSA.

Como asignar el permiso Perform volume maintenance tasks

Ahora que ya sabes lo que implica la asignación de este privilegio de Windows vamos a ver como concederlo. Como ya hemos visto, durante la instalación tenemos un check que nos lo asignará automáticamente pero, si no lo hemos hecho, o si hemos cambiado la cuenta de servicio de SQL Server, será necesario hacerlo manualmente. Hemos visto que se otorga a través de las directivas de windows por lo que, lo primero que necesitaremos será abrir la consola gpedit.msc. Una vez en el editor de directivas nos iremos a Configuración del equipo – Configuración de Windows – Configuración de seguridad – Directivas locales – Asignación de derechos de usuario. En este apartado encontraremos el permiso “Realizar tareas de mantenimiento del equipo” al que añadiremos nuestra cuenta de servicio de SQL Server. Una vez cambiado esto será necesario reiniciar el servicio de SQL Server para aplicar los cambios.

Perform-volume-maintenance-tasks

Pruebas de rendimiento

Para terminar quiero compartir con vosotros una prueba de rendimiento que he hecho en mi equipo. Para la prueba, sin haber asignado el permiso a la cuenta de SQL, he creado unas bases de datos de 10 Gb de tamaño inicial en 3 discos duros, un M2, un SSD y un HDD. Luego he realizado la misma prueba pero con el privilegio otorgado. Estos son los resultados: 

 M2SSDHDD
CON Inicialización instantánea86 ms127ms852 ms
SIN Inicialización instantánea88 ms174 ms1118 ms

Conclusión

Configurar el permiso para realizar tareas de mantenimiento sobre los volúmenes puede tener mejoras sustanciales en la creación o redimensionamiento de los ficheros de bases de datos. Sin embargo, tiene implicaciones de seguridad que es necesario conocer y valorar previamente. Además, aunque la mejora de rendimiento sea notable, sigue sin ser recomendable confiar en el crecimiento automático, siendo necesario dimensionar previamente los ficheros para evitar problemas. 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, 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

Descifrar contraseñas de usuarios de SQL

En el video de hoy vamos a ver como funciona la función PWDCOMPARE. Como sabeís SQL Server almacena las contraseñas de los usuarios en un hash que podemos ver pero no descifrar. Aquí es donde entra en juego PWDCOMPARE, gracias a esta poderosa función de SQL Server vamos a poder comparar los hash de contraseñas almacenados en SQL Server con cadenas de caracteres en texto plano. Esto nos va a permitir simular ataques de diccionario o fuerza bruta para comprobar la seguridad de las contraseñas nuestros usuarios.

Dejadme en comentarios si os interesa que dediquemos un post a crear un script para validar automáticamente las palabras de un diccionario, los nombres de los usuarios y del servidor como contraseñas y así auditar mejor la seguridad de vuestra instalación de SQL Server o Azure SQL.

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, SQL Server, Videos, 0 comentarios

Como usar la clasificación de datos en SQL Server

Ayer vimos como para cumplir con los reglamentos de protección de datos tipo RGPD lo primero que debemos hacer es una correcta clasificación de los datos. En ese post os expliqué también como SQL Server incorpora de forma nativa tanto en sus versiones On Premise como en las versiones de Azure una herramienta para clasificar los datos por tipo y sensibilidad.

Eso es justo lo que quiero enseñaros en el video de hoy. En poco menos de 5 minutos os voy a enseñar como acceder a esta opción, como la clasificación automática de los datos es capaz de identificar nuestras columnas más sensibles y como podemos nosotros añadir nuevas columnas a esta clasificación. Además os voy a mostrar el reporte que podremos obtener después con los datos que han sido clasificados.

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, SQL Server, Videos, 1 comentario

RGPD en SQL y Azure: Clasificación y Cifrado de datos

No es sorpresa para ninguno de vosotros si os digo que hoy en día, cumplir con la protección de datos es más importante que nunca. Y no es para menos, el incumplimiento de estas normas puede acarrear sanciones para la empresa de hasta 20 millones de euros o el 4% de la facturación global anual, lo que sea más. La Regulación General de Protección de Datos (RGPD) ha establecido nuevas normas y expectativas para las empresas en lo que respecta a la gestión de datos personales y en este artículo, nos centraremos en cómo SQL Server puede ayudarnos a cumplir con ellas. Para ello vamos a centrarnos por un lado en la detección y clasificación de datos sensibles y por otro en las distintas soluciones nativas de cifrado y protección de estos datos.

¿Qué es el RGPD?

Antes de entrar a ver las actuaciones que tenemos que llevar a cabo en SQL Server para cumplir con la normativa, es importante que definamos los conceptos básicos que debemos conocer sobre la RGPD. No te asustes, no voy a entrar en mucho detalle, esto no es un blog legal. 

El RGPD (GDPR por sus siglas en inglés) es una ley europea que obliga a las empresas a proteger los datos personales, no solo de sus clientes y empleados sino de toda persona que tenga algún tipo de interacción con ellos. Aunque entró en vigor en 2016 y es de obligado cumplimiento desde 2018, no es raro encontrarnos con escenarios que no están completamente adaptados a ella, ya sea porque son empresas de reciente creación o porque hasta ahora no habían tenido esta necesidad.

Dentro de los datos que vamos a necesitar proteger para cumplir con el reglamento encontramos los siguientes:

  • Datos identificativos: nombre, apellidos, dirección, email, teléfono, firma, DNI y, en definitiva, cualquier dato que sirva para identificarnos.
  • Datos personales: Fecha de nacimiento, estado civil, edad, nacionailidad, sexo, religión, etc…
  • Datos sociales: Aficiones, estilo de vida, posesiones, características de la casa, etc…
  • Datos académicos y profesionales: historial académico, experiencia profesional, puesto de trabajo, profesión, pertenencia a asociaciones profesionales, etc…
  • Datos comerciales: licencias, suscripciones a publicaciones, revistas, medios de comunicación, etc…
  • Datos financieros: Cuenta bancaria, prestamos, ingresos y nivel de renta, tarjetas, planes de pensiones, datos de la nomina u otros ingresos, tributaciones, etc…

Clasificación de Datos Sensibles para cumplir la RGPD

La clasificación de datos es un primer paso fundamental en cualquier estrategia de protección de datos. Como es lógico, antes de afrontar ninguna tarea de protección de los datos deberemos clasificarlos, detectar los que son sensibles y los que están amparados por la legislación. Tanto SQL Server como las bases de datos SQL en Azure ofrecen una funcionalidad integrada para la clasificación de datos que nos permite identificar y categorizar los datos que se deben proteger.

La clasificación de datos en SQL Server se realiza a través de dos componentes principales: Etiquetas de Sensibilidad y Etiquetas de Información. Las Etiquetas de Sensibilidad nos permiten clasificar los datos según su nivel de sensibilidad, mientras que las Etiquetas de Información nos permiten categorizar los datos según el tipo de información que contienen.

Opciones Nativas de Cifrado para cumplir la RGPD

SQL Server ofrece varias herramientas nativas de cifrado para proteger nuestros datos. Estas herramientas proporcionan una capa adicional de seguridad y nos ayudan a cumplir con los requisitos de la RGPD. Ya hemos hablado de ellas en este blog de una manera detallada en este artículo, por lo que hoy vamos a hacerlo desde el punto de vista del cumplimiento normativo.

Lo primero que tenemos que tener claro es la clasificación de las medidas de cifrado según su funcionalidad. Por un lado tendremos el cifrado en tránsito que protegerá la información de un potencial atacante a la escucha durante su movimiento por la red. El otro de los tipos de cifrado es en reposo, es decir, proteger los datos de lecturas no deseadas mientras estén almacenados. En un escenario ideal implementaremos una o varias de estas técnicas de cifrado para lograr la máxima protección. 

Cifrado en tránsito

SQL Server imprenta de forma nativa la opción de usar un certificado para la conexión de manera que podamos tener un cifrado TLS en tránsito. Para ello deberemos instalar el certificado en el servidor de SQL Server y posteriormente configurarlo para su uso en SQL Server en las propiedades del servicio del motor de base de datos. Encontraremos en estas propiedades una pestaña certificados donde configurarlo (implica reinicio del servicio). En Azure no será necesario realizar ninguna acción adicional, ya que todas las conexiones implementan el uso de TLS. Sin embargo, sí es recomendable desactivar el uso de TLS 1.0 y TLS1.1 siempre que sea posible ya que por defecto están habilitados. 

Cifrado en reposo

Otra de las opciones que tenemos disponible en SQL Server es Transparent Data Encryption (TDE). TDE cifra los datos en reposo, lo que significa que los datos se cifran cuando se almacenan en el disco. Esto protege los datos contra el acceso no autorizado en caso de que los archivos de la base de datos sean robados. Sin embargo no protege los datos sensibles de su lectura para usuarios con acceso a la base de datos. Con esta opción solo nos vamos a garantizar que nadie que no disponga del certificado y la clave correctas pueda restaurar o adjuntar nuestra base de datos.

Para proteger los datos contra las lecturas de usuarios no autorizados, aunque si tengan acceso a la base de datos tenemos dos opciones, DDM y Always Encrypted. DDM o Dynamic Data Masking es la opción más básica y menos completa. Esta opción enmascara los datos para los usuarios que no tengan un permiso específico para desenmascararlos pero el dato está almacenado en disco sin ningún cifrado. Además esta opción permitirá la lectura en plano de los datos a cualquier administrador con permisos de sysadmin sin posibilidad de ocultación. 

Si queremos realmente un cifrado completo de los datos y que no puedan ser visibles para los administradores (pero si para los usuarios autorizados) tenemos Always Encrypted. Always Encrypted es una característica que protege los datos confidenciales almacenados en las bases de datos de SQL Server. Los datos están cifrados en todo momento, tanto en reposo como en tránsito, lo que significa que los datos están protegidos tanto cuando se almacenan en la base de datos como cuando se transmiten entre la base de datos y la aplicación.

Conclusión

Cumplir con la RGPD puede no ser sencillo, pero SQL Server ofrece las herramientas y funcionalidades necesarias para hacerlo de manera efectiva. Al utilizar la clasificación de datos y las herramientas nativas de cifrado, podemos proteger nuestros datos sensibles y asegurarnos de que estamos cumpliendo con las regulaciones de protección de datos.

Recuerda, la protección de datos no es solo una obligación legal, sino también una responsabilidad ética. Al proteger los datos de nuestros clientes, no solo cumplimos con la ley, sino que también construimos confianza y lealtad con nuestros clientes. Y eso, al final del día, es lo que realmente importa. Trabaja con el responsable de los datos y el departamento legal para obtener los mejores resultados. 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, 1 comentario
Azure Data Studio vs SQL Server Management Studio (SSMS)

Azure Data Studio vs SQL Server Management Studio (SSMS)

La primera elección a la que nos vamos a enfrentar cuando vamos a trabajar con SQL Server o una instancia o base de datos de Azure por primera vez es la herramienta que vamos a usar. Existen multitud de soluciones pero las principales, y desarrolladas por Microsoft, para esta tarea son SQL Server Management Studio (SSMS) o Azure Data Studio (aquí no hay siglas, nadie usa ADS). No os dejéis llevar por los nombres, ambas soluciones nos van a permitir conectarnos de la misma manera tanto a SQL Server como a instancias o bases de datos de Azure SQL. Así que, la decisión entre una u otra será por otros aspectos que las diferencian, y eso justo es lo que hoy voy a tratar de aclararos.

¿Qué son SSMS y Azure Data Studio?

SQL Server Management Studio (SSMS) es una aplicación de código cerrado pero gratuita desarrollada por Microsoft para permitir la interacción de usuarios y administradores a las bases de datos SQL Server ya sea en instalaciones On Premise como en la nube de Azure. Además, nos permite conectarnos a otros servicios de la familia de SQL Server como son SSAS, SSRS y SSIS. Gracias a esta herramienta dispondremos de una interfaz gráfica para realizar de manera gráfica cualquier operación que necesitemos sobre SQL Server y sus objetos. Dispondremos también de la posibilidad de generar código para consulta T-SQL, DMX, MDX y DAX.

Azure Data Studio, por su parte, también es una herramienta gratuita de Microsoft pero en este caso es de código abierto. Se basa en Visual Studio Code que a su vez se basa en el Framework Electron. Esto hace que, si quieres, puedas colaborar en el código de Azure Data Studio en GitHub. Si lo comparamos con SSMS estaremos ante una aplicación visualmente más moderna, más ligera y extensible. En el caso de Azure Data Studio, al igual que en Visual Studio Code, podremos instalar componentes ya sean de Microsoft o de terceros para ampliar las funcionalidades que nos ofrece. Por ejemplo, podemos agregar compatibilidad con bases de datos MySQL o PostgreSQL. 

Compatibilidad Multiplataforma

SSMS lleva en el mercado desde SQL Server 2005, y aunque ha ido mejorando y añadiendo funcionalidades (ya va por la versión 20.1), en esencia es la misma aplicación Win32 para escritorios Windows. No tiene soporte para MacOS ni para Linux y eso restringe su uso a servidores o estaciones clientes con un sistema operativo Windows.

Azure Data Studio, por el contrario, al estar basado en Visual Studio es multiplataforma y podremos instalarlo en equipos Windows, Linux o Mac (no como SSMS que solo es compatible con Windows).

¿A quién va dirigido SSMS y Azure Data Studio?

SSMS es una aplicación dirigida a desarrolladores SQL Server y administradores de bases de datos o profesionales de sistemas que deban administrar Servidores SQL Server. Incluye todas las opciones de administración de forma gráfica y nos permite adaptar cualquier configuración con unos pocos clics de ratón. Gracias al soporte ampliado de las nuevas versiones, además, vamos a poder administrar de la misma manera Azure Managed Instances, Azure Databases o pools de Azure Synapse SQL. Por último, como ya hemos comentado, también vamos a poder usar SSMS para conectar con SSAS, SSRS y SSIS.

Azure Data Studio, por el contrario, es una aplicación centrada en su uso por profesionales de datos y BI y desarrolladores por lo que prescinde de todas las opciones de administración que nos brinda SSMS. Esto hace que sea una aplicación mucho más ligera como hemos comentado antes. No quiere decir que desde Azure Data Studio no vayamos a poder administrar nuestros servidores, si vamos a poder, simplemente tendremos que hacerlo por comandos T-SQL. Mucho más engorroso, ¿verdad?. Si nos gustase eso administraríamos Servidores Oracle y ganaríamos más dinero. Con Azure Data Studio tendremos la posibilidad de conectarnos a SQL Server On Premise, Azure Database, Azure Managed Instance, Azure Synapse así como a MySQL y a PostgreSQL. Sin embargo, y esto es una cosa que no entiendo, no tiene soporte para bases de datos NOSQL como la propia CosmoDB de Azure.

Características

En cuanto a la comparativa propiamente dicha, como venimos comentando, está entre las funciones que cada una de las aplicaciones nos brinda. Vamos primero a ver las características comunes a ambas aplicaciones y luego sus diferencias. Ambas tienen un editor de consultas que admite T-SQL, DMX, MDX, DAX y XMLA (SSAS) y se apoyan en IntelliSense para facilitarnos la tarea. También disponen de un explorador para visualizar jerárquicamente los objetos que componen nuestra base de datos. 

Como diferencias, SSMS dispone de un gran arsenal de herramientas pensadas para administradores y usuarios más avanzados de SQL Server entre las que podemos destacar las relacionadas con la seguridad, el mantenimiento y el Agente de SQL Server. Disponemos también de Query Store y una serie de informes predefinidos para las bases de datos que nos aportarán información muy valiosa.

Azure Data Studio, cuenta en su haber con otras características exclusivas como los cuadernos Jupyter, integración con GitHub y con Copilot y la posibilidad de instalar extensiones. Además soporta los lenguajes de programación Python, R y Scala.

Para cerrar este apartado, quiero destacar la integración entre SSMS y Azure Data Studio. Si disponemos de ambas aplicaciones instaladas, desde SSMS vamos a poder abrir Azure Data Studio directamente para poder trabajar con los cuadernos Jupyter. 

SSMS_AzureDataStudio

Tampoco sería justo dejar de mencionar que, si bien Azure Data Studio no está pensado para administrar servidores, poco a poco se van añadiendo funcionalidades para este fin. En el momento de escribir estas líneas, podemos encontrar cómo Preview funcionalidades avanzadas hasta ahora exclusivas de SSMS.

AzureDataStudio_Manage

Conclusión

Azure Data Studio y SSMS son dos poderosísimas herramientas desarrolladas por Microsoft para facilitarnos nuestras interacciones diarias con SQL y Azure. Elegir una u otra dependerá de nuestras necesidades ya que no están pensadas para el mismo público objetivo y por tanto no disponen de exactamente las mismas funcionalidades. En mi caso trabajo siempre con ambas aplicaciones abiertas y depende la tarea que tenga que realizar en ese momento uso la que mejor se adapte. Espero que gracias a este artículo vosotros podáis tomar la mejor decisión informada y veáis cubiertas vuestras necesidades. Como siempre, estamos aquí para ayudarte. 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, 1 comentario