Comparer une base de données et un projet
S’applique à : 
SQL Server Azure SQL Database Azure SQL Managed Instance
La compréhension des différences de définition des objets entre une base de données et un projet SQL peut fournir des informations précieuses sur l'état de votre base de données et de votre projet, y compris pendant le développement en cours ou la résolution des problèmes de régression. Les projets SQL comprennent des outils permettant de visualiser les différences, d'analyser les changements nécessaires à la mise à jour d'une base de données, d'importer les changements d'une base de données dans un ensemble de fichiers projet SQL et d'examiner les scripts T-SQL qui seraient exécutés pour mettre à jour une base de données afin qu'elle corresponde au projet.
Cet article passe en revue les méthodes de comparaison d'une base de données et d'un projet SQL en utilisant différentes approches :
- Vous pouvez utiliser la comparaison de schémas pour visualiser les différences entre les bases de données et/ou les projets. Cette comparaison peut vous aider à identifier les modifications qui doivent être synchronisées entre la base de données et le projet.
- Vous pouvez utiliser un rapport de déploiement pour résumer et automatiser l'examen des modifications nécessaires à la mise à jour d'une base de données.
- Vous pouvez utiliser la comparaison de schémas ou l'extraction SqlPackage pour importer les modifications d'une base de données dans un ensemble de fichiers projet SQL.
- Vous pouvez utiliser le script de déploiement SqlPackage ou la comparaison de schéma pour examiner les instructions T-SQL qui sont exécutées pour mettre à jour une base de données afin qu'elle corresponde au projet.
Comparaison de schémas : visualiser les différences
Prérequis
La comparaison de schémas graphiques n’est pas encore disponible dans la préversion des projets SQL de style SDK dans Visual Studio. Utilisez Azure Data Studio ou Visual Studio pour comparer les schémas.
La comparaison de schémas nécessite un outil graphique tel que Visual Studio ou Azure Data Studio.
Résumé
La comparaison de schémas fournit l'interface visuellement la plus riche pour comprendre les différences entre une base de données et un projet. L'une des capacités clés de la comparaison de schémas réside dans le fait que la direction de la comparaison est réversible. Par conséquent, vous pouvez utiliser la comparaison de schémas pour comprendre les modifications d'un projet à déployer dans une base de données ou les modifications d'une base de données à ajouter à un projet. Vous pouvez utiliser la comparaison de schémas pour identifier les différences dans les définitions d'objets, tels que les tables, les vues, les procédures stockées et les fonctions.
L'ensemble des différences ou un sous-ensemble sélectionné peut être utilisé pour appliquer les modifications à la base de données ou au projet. La comparaison de schémas peut également générer un script de déploiement qui, lorsqu'il est exécuté, applique effectivement les modifications à une base de données.
Pour en savoir plus sur la comparaison de schémas, consultez la vue d'ensemble de la comparaison de schémas.
Rapport de déploiement : révision des modifications
Le rapport de déploiement nécessite l'utilisation de l'interface CLI SqlPackage.
dotnet tool install -g Microsoft.SqlPackage
Résumé
Un rapport de déploiement fournit un résumé des changements nécessaires pour mettre à jour une base de données afin qu'elle corresponde à un projet. L'interface CLI SqlPackage génère un rapport de déploiement en comparant un modèle source (artefact de génération de projet .dacpac SQL ou base de données) avec une base de données cible. Par exemple, la commande suivante génère un rapport de déploiement pour une base de données nommée MyDatabase à partir d'un projet SQL nommé MyProject :
dotnet build MyProject.sqlproj
sqlpackage /Action:deployreport /SourceFile:bin/Debug/MyProject.dacpac /TargetConnectionString:{connection string for MyDatabase} /OutputPath:deployreport.xml
Le fichier XML produit est une forme simplifiée du plan de déploiement, résumant les opérations qui seraient effectuées si un déploiement de base de données était exécuté. La liste des opérations suivantes n'est pas exhaustive :
CreateAlterDropRefreshUnbindSchemaBindingUnbindFulltextIndexTableDataMotionSPRenameEnableChangeTrackingDatabaseDisableChangeTrackingDatabase
Un rapport de déploiement peut être révisé dans un éditeur de texte ou dans Visual Studio et ressemblerait à ce qui suit :
<?xml version="1.0" encoding="utf-8"?>
<DeploymentReport xmlns="http://schemas.microsoft.com/sqlserver/dac/DeployReport/2012/02">
<Alerts />
<Operations>
<Operation Name="Create">
<Item Value="[CO].[Products].[IX_Products_CategorySlug]" Type="SqlIndex" />
</Operation>
<Operation Name="Alter">
<Item Value="[CO].[Brands]" Type="SqlTable" />
<Item Value="[CO].[AddProductImage]" Type="SqlProcedure" />
</Operation>
<Operation Name="Refresh">
<Item Value="[CO].[SelectStarView]" Type="SqlView" />
</Operation>
</Operations>
</DeploymentReport>
Un rapport de déploiement peut être utilisé pour examiner les modifications et surveiller les événements à fort impact potentiel, tels que le déplacement de données ou la création/suppression d'index cluster. Ces événements seraient listés dans le rapport de déploiement sous l'élément Alerts.
L'opération de rapport de déploiement XML présente l'avantage de pouvoir être utilisée pour automatiser la révision des modifications nécessaires à la mise à jour d'une base de données. Le XML peut être analysé et utilisé pour générer un rapport ou pour déclencher des alertes sur la base des opérations ou des noms d'objets listés.
Importer des modifications à partir d’une base de données
Comme indiqué dans la section sur la comparaison de schémas, la comparaison de schémas peut être utilisée pour appliquer les modifications d'une base de données à un jeu de fichiers projet SQL. L'application de modifications à un projet SQL est un scénario courant lorsque vous disposez d'une base de données activement développée en direct et qu'un projet SQL est utilisé pour manager les objets de la base de données dans le contrôle de code source. L'exécution manuelle de cette opération via Visual Studio ou Azure Data Studio peut prendre beaucoup de temps, en particulier lorsque la base de données comporte de nombreux objets ou des modifications sporadiques. Dans cette section, nous verrons comment automatiser l'extraction des définitions d'objets d'une base de données vers un jeu de fichiers projet SQL.
Prérequis
En mettant l'accent sur l'automatisation, nous utilisons l'interface CLI SqlPackage pour extraire les définitions d'objets d'une base de données dans un ensemble de fichiers projet SQL. Les modèles Microsoft.Build.Sql.Templates .NET sont utilisés pour créer un fichier projet SQL, une étape facultative.
# install SqlPackage CLI
dotnet tool install -g Microsoft.SqlPackage
# install Microsoft.Build.Sql.Templates
dotnet new install Microsoft.Build.Sql.Templates
Résumé
La commande d'extraction SqlPackage prend une base de données source et génère un modèle de base de données en sortie, soit sous la forme d'un fichier .dacpac, soit sous la forme d'un jeu de scripts SQL. SqlPackage génère par défaut un fichier .dacpac, mais la propriété /p:ExtractTarget= peut être utilisée pour spécifier un jeu de scripts SQL. La commande suivante extrait la base de données MyDatabase dans un fichier projet SQL placé dans le dossier MyDatabaseProject :
sqlpackage /Action:Extract /SourceConnectionString:{connection string for MyDatabase} /TargetFile:MyDatabaseProject /p:ExtractTarget=SchemaObjectType
Lorsqu'un dossier est sous contrôle de code source, les définitions d'objets extraites montrent des différences dans les outils de contrôle de code source. En utilisant SqlPackage pour générer les fichiers et vérifier les différences dans le contrôle de code source, vous pouvez automatiser le processus d'importation des modifications d'une base de données dans un ensemble de fichiers projet SQL.
En une série de trois commandes, nous pouvons supprimer l'ensemble des fichiers précédents, extraire la base de données et vérifier les différences dans les outils de contrôle de code source :
rm -rf MyDatabaseProject
sqlpackage /Action:Extract /SourceConnectionString:{connection string for MyDatabase} /TargetFile:MyDatabaseProject /p:ExtractTarget=SchemaObjectType
git status --porcelain | wc -l
Notre production est le nombre de fichiers qui ont été modifiés par la dernière extraction de SqlPackage. La production de la commande git status peut être utilisée pour déclencher d'autres étapes d'automatisation. Si nous voulons utiliser ce jeu de fichiers comme projet SQL, nous pouvons utiliser les modèles Microsoft.Build.Sql.Templates .NET pour créer un fichier projet SQL dans le dossier MyDatabaseProject :
dotnet new sqlproj -n MyDatabaseProject -o MyDatabaseProject
Révision des scripts T-SQL de déploiement
Comme indiqué dans la section sur la comparaison des schémas, la comparaison des schémas peut être utilisée pour générer les scripts T-SQL nécessaires à la mise à jour d'une base de données pour qu'elle corresponde à un projet SQL. Dans cette section, nous verrons comment utiliser SqlPackage pour automatiser la génération des scripts T-SQL nécessaires à la mise à jour d'une base de données en fonction d'un projet SQL, de sorte qu'ils puissent être stockés en tant qu'artefact de pipeline pour examen et approbation.
Prérequis
dotnet tool install -g Microsoft.SqlPackage
Résumé
L'exécution d'un déploiement de projet SQL avec SqlPackage utilise l'action de publication, mais si nous voulons examiner les scripts T-SQL qui sont exécutés, nous pouvons utiliser l'action de script. La commande suivante génère les scripts T-SQL nécessaires pour mettre à jour une base de données nommée MyDatabase afin qu'elle corresponde à un projet SQL nommé MyProject :
dotnet build MyProject.sqlproj
sqlpackage /Action:Script /SourceFile:bin/Debug/MyProject.dacpac /TargetConnectionString:{connection string for MyDatabase} /DeployScriptPath:Deployment.sql