SQL Source Control se branche sur SSMS et connecte vos bases de données à votre système de contrôle de version, ce qui vous permet de contrôler la version de vos schémas de base de données, puis de les déployer à l’aide du moteur de comparaison fiable de Redgate, SQL Compare.
La dernière version (expédiée cette semaine !) comporte une version améliorée des scripts de migration, qui vous permettent d’écrire votre propre SQL pour remplacer le script de déploiement généré par SQL Compare, ce qui permet à vos coéquipiers d’obtenir les dernières modifications du contrôle de version sans risque de perdre des données. Vous pouvez en savoir plus sur ce que nous avons fait, et pourquoi, dans un autre de mes billets de blog récents.
Mais ici, je voulais vous parler de la façon dont cela fonctionne en utilisant un scénario commun.
Comment éviter la perte de données lors du renommage d’une table
Les tâches courantes qui pourraient être affectées comprennent la division ou la fusion de colonnes et de tables, l’ajout d’une contrainte NOT NULL à une colonne, la modification du type de données ou de la taille d’une colonne, et le renommage d’une table.
Dans le cas du renommage d’une table sur votre base de données de développement, SQL Source Control interpréterait cette modification comme un DROP et un CREATE. Si un autre membre de votre équipe utilise l’onglet Get latest pour obtenir ces modifications, les données de la table cible sont perdues.
Pour éviter cette perte de données, vous pouvez écrire un script de migration pour renommer la table à l’aide de la procédure stockée sp_rename. Ce script remplace les instructions DROP et CREATE que le moteur SQL Compare générerait autrement pour cette modification.
Une fois que vous avez renommé votre table (dans ce cas, des utilisateurs aux clients), l’étape suivante consisterait à valider les modifications dans votre système de contrôle de la source à l’aide de l’onglet Commit changes dans SQL Source Control. SQL Source Control vous préviendra qu’une perte de données peut se produire en engageant la modification et vous suggérera d’écrire un script de migration.
Sur l’onglet Migrations et sous Remplacer les modifications de schéma non engagées, vous utiliseriez alors les cases à cocher pour sélectionner les modifications de schéma pertinentes.
Dans cet exemple, vous remplacez les modifications de schéma non validées parce que vous avez déjà renommé la table, mais ne l’avez pas encore validé. Le renommage est en fait interprété par SQL Compare comme un DROP et un CREATE et le script de migration remplacera ces modifications dans le script de déploiement (l’autre option serait de commencer avec un script vierge, ce que vous feriez si vous aviez déjà préparé votre schéma pour la migration et validé ces modifications).
En cliquant sur Générer le script, SQL Source Control génère un script de migration basé sur les modifications non validées et vous pouvez alors remplacer les instructions DROP et CREATE générées automatiquement.
Dans ce cas, nous utiliserions le SQL suivant:
EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO
Le synonyme de la table clients ici évitera les problèmes où la table est référencée en utilisant l’ancien nom.
Puis vous pouvez Enregistrer et fermer et ce script de migration remplace maintenant les changements effectués.
De retour dans l’onglet Commit, vous verrez le script de migration avec les changements de schéma associés nichés en dessous. Il ne vous reste plus qu’à sélectionner le nouveau script de migration, à saisir un commentaire et à valider les modifications.
Vous êtes maintenant prêt à déployer les modifications. Si vous utilisez SQL Compare, alors le script de migration est automatiquement exécuté pendant le déploiement, en utilisant la procédure stockée sp_rename à la place des instructions DROP et CREATE générées à l’origine par le moteur SQL Compare.