Conectar DatabaseSpy a una base de datos SQL Azure en la nube

Consejos y técnicas para facilitar la implementación de la base de datos SQL Azure, basada en la nube de Microsoft, en entornos de producción, fueron los temas principales en la conferencia Tech-Ed de Nueva Orleans en junio. SQL Azure se basa en las tecnologías de Microsoft SQL Server y está diseñada para ofrecer un servicio de base de datos altamente disponible y escalable, alojado por Microsoft en la nube. Los desarrolladores que implementan bases de datos en SQL Azure no tienen que instalar, configurar, aplicar parches ni administrar ningún software de base de datos relacional, solo su propia estructura y contenido de la base de datos. La redundancia y la tolerancia a fallos son características integradas, y no se requiere ninguna administración física.

Puede crear una cadena de conexión manual y utilizar la sintaxis y los tipos de datos de SQL Server para conectar DatabaseSpy y otras herramientas de Altova a las bases de datos de SQL Azure, con el fin de realizar tareas típicas de desarrollo y mantenimiento de bases de datos. Esta entrada de blog muestra cómo conectarse a una base de datos SQL Azure desde DatabaseSpy y demuestra varias operaciones típicas que podría ser necesario realizar al migrar una base de datos existente a la nube. Para seguir estos pasos por su cuenta, necesitará una cuenta de SQL Azure, o un nombre de usuario y contraseña creados por un titular de una cuenta de SQL Azure. Para obtener más información sobre cómo configurar una cuenta de SQL Azure, visite la página principal de SQL Azure de Microsoft. También deberá instalar Cliente nativo de SQL Server 10.0 (o posteriormente). SQL Azure no funciona exactamente como una base de datos local de SQL Server, por lo que no podemos utilizar el asistente de conexión a SQL Server de Altova. En lugar de eso, utilizaremos una conexión ODBC.

No vamos a detallar todos los aspectos del proceso de creación de una nueva cadena de conexión aquí. Puede copiar y pegar una cadena de conexión existente en el cuadro de diálogo que se muestra arriba.

Una vez que se conecta a SQL Azure por primera vez, un archivo de proyecto de DatabaseSpy le permite guardar todas sus configuraciones de conexión, junto con los scripts SQL más utilizados, los archivos de diseño de bases de datos y las comparaciones de bases de datos, en un único archivo para poder cargarlos fácilmente más adelante. La captura de pantalla que se muestra a continuación ilustra un nuevo proyecto de DatabaseSpy con dos bases de datos conectadas simultáneamente: Sakila en MySQL y Sakila en la nube en SQL Azure.

Microsoft ofrece una serie de herramientas de conversión para ayudar a los usuarios a migrar bases de datos existentes a la plataforma SQL Azure. Utilizamos el asistente de migración de SQL Server para MySQL de Microsoft para convertir nuestra base de datos de ejemplo local de MySQL, Sakila, a nuestra cuenta de SQL Azure. DatabaseSpy permite a los usuarios abrir múltiples conexiones simultáneamente, incluso a bases de datos de diferentes tipos. La función de comparación de bases de datos de DatabaseSpy la convierte en una herramienta ideal para verificar los resultados de la conversión de Sakila. Primero, abriremos una comparación de esquemas de bases de datos y seleccionaremos algunas tablas de la base de datos MySQL para el lado izquierdo de la comparación.

Una vez que seleccionamos las tablas correspondientes en la versión de SQL Azure, estas se abren en una ventana de comparación de esquemas de bases de datos.

Cuando hacemos clic en el botón verde de "comparar" que se encuentra en la esquina superior izquierda de la ventana, DatabaseSpy compara las estructuras de la base de datos, destaca las diferencias y genera un resumen en la ventana de mensajes.

Algunas diferencias corresponden a definiciones de tipos de datos que varían entre las bases de datos. Por ejemplo, el tipo "unsigned small int" de MySQL no tiene un equivalente exacto en SQL Server, por lo que la herramienta de conversión sustituyó el tipo "int" por la columna "film_id" en la tabla "film". Además, el tipo de datos "year" asignado a la columna "release_year" en MySQL se ha convertido a "smallint" en SQL Azure. Creo que esto hará que la versión de la base de datos en SQL Azure sea más compatible con versiones futuras, ya que podrá almacenar información sobre películas lanzadas hasta el año 32.767, en comparación con 2155, que es el valor máximo del tipo de datos "year" en MySQL. Podemos comparar los datos contenidos en las dos bases de datos a través de una opción en el menú contextual al hacer clic derecho, lo que abrirá las tablas seleccionadas en una nueva ventana de comparación de datos.

La comparación de los datos nos muestra que el contenido de las tablas no es idéntico.

Al abrir la ventana de resultados, vemos que la columna de descripción no se migró correctamente.

Al revisar la ventana de comparación de esquemas de base de datos, podemos ver que la longitud de la columna de descripción se había establecido en cero. Esto explica las flechas rojas que apuntan desde la columna de descripción en MySQL hacia la columna de descripción en SQL Azure en la ventana de resultados. No podemos copiar ninguna cadena de texto en una columna que tenga una longitud definida de cero. En lugar de eso, abramos la versión de la tabla de películas en SQL Azure en una nueva ventana de diseño.

Podemos aumentar el tamaño del campo de descripción en la ventana de propiedades y, a continuación, ejecutar el script resultante para aplicar el cambio.

A continuación, al volver a ejecutar la comparación de datos, descubrimos que los datos fueron convertidos, pero la longitud de campo previamente definida como cero hizo que los datos fueran invisibles.

Problemas de latencia Puede utilizar DatabaseSpy para analizar los problemas de latencia entre la base de datos en la nube y la copia local. Como se observó en la comparación de datos anterior, las tablas de películas en las dos bases de datos contienen 1000 filas de datos idénticos. Podemos ejecutar repetidamente sentencias SELECT para recuperar los datos de SQL Azure y de la base de datos MySQL local, con el fin de medir el tiempo de ejecución. La ventana de mensajes del editor SQL de DatabaseSpy muestra el tiempo de ejecución.

La ejecución de la instrucción SELECT mencionada anteriormente, repetida cinco veces consecutivas en la versión de SQL Azure de la base de datos sakila, generó resultados que oscilaron entre 60.632 segundos y 63.851 segundos. La ejecución de la misma instrucción SELECT para la misma tabla de películas en la base de datos MySQL local produjo el siguiente resultado:

Repetir la prueba para la versión local generó tiempos similares. La conclusión para los desarrolladores es que su aplicación, que depende de una base de datos, probablemente necesitará adaptarse a la latencia a medida que trasladen sus datos a la nube. Prueben su propia conexión a SQL Azure con una prueba gratuita de Altova DatabaseSpy.