SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

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

Optimización de Consultas con OPTION RECOMPILE

Cuando hablamos de consultas sobre las bases de datos, la eficiencia es clave. Como DBAs siempre buscamos formas de mejorar el rendimiento de las consultas. Pero no solo nosotros, los DBAs, nos vemos en esta necesidad, cualquier desarrollador que trabaje con bases de datos también debe perseguir el mismo objetivo. En este contexto, a veces, la solución puede ser tan simple como usar la sugerencia de consulta OPTION RECOMPILE. Pero, ¿qué es exactamente y cómo puede ayudarnos en SQL Server y Azure SQL? ¿Realmente es una solución mágica que podemos usar siempre como una carta comodín? Durante estas líneas voy a tratar de dar respuesta a estas preguntas.

¿Qué es OPTION RECOMPILE?

OPTION RECOMPILE es una directiva que podemos agregar al final de nuestras consultas en SQL Server para indicar que queremos que se recompile el plan de ejecución cada vez que se ejecuta la consulta. Esto puede ser útil en situaciones donde los datos subyacentes cambian con frecuencia y queremos asegurarnos de que estamos utilizando el plan de ejecución más eficiente posible.

Banner-Telegram

¿Cómo funciona OPTION RECOMPILE?

Para entender este concepto, es importante recordar algunos de los conceptos que hemos discutido en artículos anteriores. En concreto hablo de los planes de ejecución de las consultas y de la caché de planes de ejecución.

Planes de ejecución

En nuestro artículo sobre planes de ejecución, exploramos cómo SQL Server y Azure SQL crean y utilizan estos planes para llevar a cabo las consultas de manera eficiente. Estos planes son esenciales para entender cómo OPTION RECOMPILE puede mejorar el rendimiento de nuestras consultas.

Caché de planes de ejecución

Además, en nuestro artículo sobre la caché de planes, vimos cómo SQL Server y Azure SQL almacenan los planes de ejecución para su reutilización. Este almacenamiento en caché puede ser muy eficiente, pero también puede llevar a problemas si los datos subyacentes cambian con frecuencia, lo que nos lleva de nuevo a la utilidad de OPTION RECOMPILE.

Option Recompile

Ahora sí, vamos a dar respuesta a la pregunta ¿cómo funciona OPTION RECOMPILE?

Ya sabemos que la primera vez que ejecutamos una consulta en SQL Server o Azure SQL, el motor de la base de datos crea un plan de ejecución. Este plan es básicamente una serie de pasos que la base de datos seguirá para recuperar los datos solicitados. Una vez que se ha creado un plan, además de usarse para la consulta en curso, se almacena en caché para su uso en futuras ejecuciones de la misma consulta. 

Sin embargo, esto que la mayoría de las veces es una ventaja, puede no serlo si los datos subyacentes cambian significativamente. En estos casos el plan almacenado en caché puede no ser el más eficiente. También puede pasar que las estadísticas de la tabla no estuvieran bien actualizadas al momento de compilar el primer plan de ejecución y no este sea del todo correcto. Aquí es donde entra en juego OPTION RECOMPILE. Al agregar esta directiva a nuestra consulta, le estamos diciendo al motor de base de datos de SQL Server que ignore cualquier plan almacenado en caché y genere uno nuevo. 

Esto no quiere decir que se vaya a usar un plan de ejecución distinto, simplemente el motor de base de datos va a analizar todas las opciones posibles para resolver la consulta y a elegir el que le parezca más óptimo. Puede ser que vuelva a elegir el mismo, sobre todo si tenemos un problema con las estadísticas.

¿Cuándo deberíamos usar OPTION RECOMPILE?

Aunque OPTION RECOMPILE puede ser una herramienta poderosa, no siempre es la mejor opción. La recompilación de un plan de ejecución tiene un coste en términos de recursos, en concreto en consumo de CPU, por lo que si una consulta se ejecuta con mucha frecuencia, el coste de la recompilación puede superar cualquier beneficio de rendimiento que obtengamos.

Por lo tanto, OPTION RECOMPILE es más adecuado para consultas que se ejecutan con poca frecuencia, pero que son críticas para el rendimiento, o para consultas donde los datos subyacentes cambian con tanta frecuencia que un plan almacenado en caché se vuelve ineficiente rápidamente. En esta línea, otro posible escenario son las consultas de procedimientos almacenados que interactúan con datos con gran variación entre un parámetro y otro. Para estos casos de gran desigualdad en los volúmenes de datos puede ser una gran alternativa a la utilización tradicional de planes en caché.

Personalmente también me gusta mucho utilizar esta opción de consulta cuando me enfrento a un problema de rendimiento de una consulta. En estas situaciones puede ser de gran ayuda, localizar a tiempo que el problema está en un plan de ejecución no óptimo cacheado puede ahorrarnos mucho tiempo y esfuerzo en la optimización.

Conclusión

En resumen, OPTION RECOMPILE es un truco muy potente y valioso en nuestra caja de herramientas de optimización de consultas. Aunque no es una solución para todos los problemas de rendimiento, y hay que medir muy bien su uso para no caer en problemas mayores, puede ser extremadamente útil en las circunstancias adecuadas. Como siempre, la clave es entender cómo funciona y cuándo usarlo. Y como digo siempre, solo plantéate este tipo de soluciones si realmente tienes un problema, las soluciones “por si acaso” nunca suelen ser una buena idea.  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, SQL Server, 0 comentarios

Borrar Duplicados en con T-SQL en Server y Azure SQL

Sexto Video Blog del canal, vamos a ver varios casos prácticos sobre como borrar registros duplicados en nuestras tablas de base de datos SQL o Azure. En el video vemos como debemos actuar para localizar y eliminar los duplicados tanto cuando tenemos un ID único como si no lo tenemos y queremos usar %%physloc%%.

%%physloc%% es una columna virtual que ofrece SQL Server desde 2008 que nos devuelve un hash de la ubicación física de los datos en el disco duro. Esto es en si mismo un identificador único de cada fila pues en una misma ubicación solo puede haber un dato. Para cada uno de estos escenarios os muestro tres ejemplos: con una subconsulta, con la función ROW_Number y una CTE y por último con la función RANK.

Cuando eliminamos los registros duplicados mantenemos nuestro modelo de datos normalizado. De esta manera lograremos optimizar el rendimiento y el espacio que ocupan nuestros datos en disco.

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

Usar PERFMON para detectar problemas de rendimiento de SQL

En este quinto video blog vamos a aprender a usar el monitor de rendimiento de Windows (PERFMON) para medir el rendimiento de SQL Server y poder detectar cuando hay algún problema. Es importante conocer previamente el estado normal de nuestros servidores para ser capaces de identificar cuando estamos ante un problema de rendimiento.

En el video hemos visto como usar en perfmon las métricas de uso de CPU combinadas con los lotes por segundo que procesa SQL Server así como la velocidad de lectura y escritura de los discos. Además de estas métricas también podemos revisar las compilaciones y recompilaciones de nuestro SQL Server cuyo valor ideal será un 10% o menos del total de lotes por segundo.

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