Connexion de DatabaseSpy à une base de données SQL Azure dans le cloud

Des conseils et des techniques pour faciliter l'intégration de la base de données SQL Azure, basée sur le cloud de Microsoft, dans les environnements de production, ont été au cœur des discussions en juin lors de la conférence Tech-Ed à La Nouvelle-Orléans. SQL Azure est construite sur les technologies de Microsoft SQL Server et est conçue pour offrir un service de base de données hautement disponible et évolutif, hébergé par Microsoft dans le cloud. Les développeurs qui déploient des bases de données sur SQL Azure n'ont pas besoin d'installer, de configurer, de mettre à jour ou de gérer aucun logiciel de base de données relationnelle ; ils ne gèrent que la structure et le contenu de leur propre base de données. La redondance automatique et la tolérance aux pannes sont intégrées, et aucune administration physique n'est requise.

Vous pouvez créer une chaîne de connexion manuelle et utiliser la syntaxe et les types de données de SQL Server pour connecter DatabaseSpy et d'autres outils Altova aux bases de données SQL Azure, afin d'effectuer les tâches courantes de développement et de maintenance de bases de données. Cet article de blog explique comment se connecter à une base de données SQL Azure à partir de DatabaseSpy et illustre plusieurs opérations courantes que vous pourriez effectuer lors de la migration d'une base de données existante vers le cloud. Pour reproduire ces étapes par vous-même, vous aurez besoin d'un compte SQL Azure, ou d'un nom d'utilisateur et d'un mot de passe créés par un utilisateur disposant d'un compte SQL Azure. Pour plus d'informations sur la création d'un compte SQL Azure, veuillez consulter le site de Microsoft Page d'accueil de SQL Azure. Vous devrez également installer le client natif SQL Server 10.0 (ou une version ultérieure). SQL Azure ne fonctionne pas exactement comme une base de données SQL Server locale, nous ne pouvons donc pas utiliser l'assistant de connexion à SQL Server d'Altova. Au lieu de cela, nous utiliserons une connexion ODBC.

Nous ne détaillerons pas toutes les étapes du processus de création d'une nouvelle chaîne de connexion ici. Vous pouvez copier-coller une chaîne de connexion existante dans la fenêtre de dialogue indiquée ci-dessus.

Une fois que vous vous connectez à SQL Azure pour la première fois, un fichier de projet DatabaseSpy vous permet de sauvegarder tous vos paramètres de connexion, ainsi que les scripts SQL fréquemment utilisés, les fichiers de conception de base de données et les comparaisons de bases de données, dans un seul fichier pratique que vous pourrez recharger ultérieurement. La capture d'écran ci-dessous montre un nouveau projet DatabaseSpy avec deux bases de données connectées simultanément : Sakila dans MySQL et Sakila dans le cloud, sur SQL Azure.

Microsoft propose un certain nombre d'outils de conversion pour aider les utilisateurs à migrer leurs bases de données existantes vers la plateforme SQL Azure. Nous avons utilisé l'outil SQL Server Migration Assistant for MySQL de Microsoft pour convertir notre base de données MySQL Sakila, qui est une base de données d'exemple locale, vers notre compte SQL Azure. DatabaseSpy permet aux utilisateurs d'ouvrir plusieurs connexions simultanément, même vers des bases de données de types différents. La fonctionnalité de comparaison de bases de données de DatabaseSpy en fait un outil idéal pour vérifier les résultats de la conversion de Sakila. Tout d'abord, nous allons ouvrir une comparaison de schémas de base de données et sélectionner quelques tables de la base de données MySQL pour le côté gauche de la comparaison.

Une fois que nous avons sélectionné les tables correspondantes dans la version SQL Azure, ces tables s'affichent dans une fenêtre de comparaison de schémas de base de données.

Lorsque nous cliquons sur le bouton vert "Comparer" situé dans le coin supérieur gauche de la fenêtre, DatabaseSpy compare les structures de la base de données, met en évidence les différences et génère un résumé dans la fenêtre de message.

Certaines différences correspondent à des définitions de types de données qui varient entre les bases de données. Par exemple, le type "unsigned small int" de MySQL n'a pas d'équivalent exact dans SQL Server, de sorte que l'outil de conversion a remplacé le type "int" par le type "smallint" pour la colonne "film_id" dans la table "film". De plus, le type de données "year" attribué à la colonne "release_year" dans MySQL a été converti en "smallint" dans SQL Azure. Je pense que cela rendra la version SQL Azure de la base de données plus compatible avec les versions futures, car elle pourra prendre en charge des films sortis jusqu'en l'an 32 767, contrairement à 2155, qui est la valeur maximale du type de données "year" dans MySQL ! Nous pouvons comparer les données contenues dans les deux bases de données en effectuant une sélection dans le menu contextuel qui apparaît en faisant un clic droit, ce qui ouvre les tables sélectionnées dans une nouvelle fenêtre de comparaison des données.

La comparaison des données révèle que le contenu des tableaux n'est pas identique.

Lorsque nous ouvrons la fenêtre des résultats, nous constatons que la colonne "description" n'a pas été correctement transférée.

En examinant la fenêtre de comparaison des schémas de base de données, on constate que la longueur de la colonne "description" a été définie à zéro. Cela explique les flèches rouges qui pointent de la colonne "description" dans MySQL vers la colonne "description" dans SQL Azure dans la fenêtre des résultats. Il est impossible de copier une chaîne de texte dans une colonne dont la longueur est définie à zéro. Au lieu de cela, ouvrons la version SQL Azure de la table "film" dans une nouvelle fenêtre de conception.

Nous pouvons augmenter la taille du champ de description dans la fenêtre des propriétés, puis exécuter le script de modification correspondant.

Ensuite, lorsque nous relançons la comparaison des données, nous constatons que les données ont été converties, mais que la longueur de champ définie précédemment, qui était de zéro, a rendu les données invisibles.

Problèmes de latence Vous pouvez utiliser DatabaseSpy pour analyser les problèmes de latence entre la base de données cloud et la copie locale. Comme nous l'avons constaté grâce à la comparaison des données ci-dessus, les tables contenant les données des films dans les deux bases de données contiennent 1 000 lignes de données identiques. Nous pouvons exécuter à plusieurs reprises des requêtes SELECT pour récupérer les données depuis SQL Azure et depuis la base de données MySQL locale, afin de mesurer les temps de réponse. La fenêtre de messages de l'éditeur SQL de DatabaseSpy affiche le temps d'exécution.

L'exécution de l'instruction SELECT ci-dessus cinq fois de suite sur la version SQL Azure de la base de données sakila a généré des résultats allant de 60,632 secondes à 63,851 secondes. L'exécution de la même instruction SELECT pour la même table de films dans la base de données MySQL locale a donné le résultat suivant :

La répétition du test pour la version locale a donné des résultats similaires. La principale conclusion pour les développeurs est que votre application, qui utilise une base de données, devra probablement prendre en compte les délais de latence lorsque vous migrez vos données vers le cloud. Essayez vous-même votre connexion à SQL Azure grâce à une version d'essai gratuite d'Altova DatabaseSpy.