Partager via

Démarrage du développement en équipe de bases de données volumineuses

  • Article

Avant de pouvoir utiliser Visual Studio pour gérer des modifications apportées à un schéma de base de données, vous créez un projet de base de données, un projet serveur ou un projet d'application de couche Données, puis vous importez des objets et des paramètres de la base de données que vous souhaitez gérer. Si vous souhaitez gérer les modifications apportées à une base de données très volumineuse, vous pouvez répartir les objets entre plusieurs projets de base de données. En optant pour cette pratique, vous pouvez contrôler les équipes ou développeurs autorisés à ajouter, modifier ou supprimer du code dans les différentes sections de la base de données.

Vous pouvez utiliser deux approches pour diviser votre base de données en unités plus petites :

  • Projets composites : vous pouvez définir des parties de votre base de données dans deux projets de base de données ou plus (dans la même solution ou vous pouvez référencer un fichier .dbschema compilé) liés par des références de projet de base de données. Lorsque vous déployez le projet qui contient la référence, vous déployez également tous les projets qu'il référence. Vous ne pouvez pas utiliser de références circulaires entre des projets dans un projet composite.

  • Projets partiels : vous pouvez exporter une partie de votre projet de base de données sous la forme d'un fichier .files. Vous créez ensuite un deuxième projet de base de données afin d'y inclure le projet partiel (le fichier .files). Vous pouvez ensuite configurer des autorisations d'accès en écriture sur les fichiers d'origine pour restreindre les modifications apportées à ces fichiers. Par conséquent, les développeurs qui travaillent sur le deuxième projet peuvent créer des objets supplémentaires qui font référence aux objets en lecture seule mais ne les modifient pas. Lorsque vous générez et déployez le deuxième projet, une copie complète de la base de données incluant les parties en lecture seule est créée. Vous pouvez utiliser des références circulaires dans un projet partiel.

Chaque approche comporte des limitations qui seront abordées ultérieurement dans cette rubrique.

Spécification d'un type de projet de base de données

Lorsque vous créez un projet de base de données, vous spécifiez le type de projet qui correspond à votre version de SQL Server. Par exemple, si la base de données que vous souhaitez gérer est basée sur SQL Server 2005, spécifiez Projet de base de données SQL Server 2005 ou Assistant SQL Server 2005. Si vous utilisez l'Assistant, vous pouvez non seulement créer le projet mais également configurer certains paramètres de génération et de déploiement et importer simultanément des objets de base de données et des paramètres.

Importation des objets et des paramètres de base de données

Après avoir créé le projet, vous pouvez importer les objets et les paramètres à partir d'une instance de base de données ou à partir d'un script. Lorsque vous importez une base de données à partir d'un script, ses définitions d'objet sont validées et les instructions qui ne peuvent pas être analysées sont placées dans le fichier ScriptsIgnoredOnImport.sql. Si vous importez des définitions d'objets qui font référence à des objets qui n'existent plus, vous devez résoudre ces erreurs avant de pouvoir générer et déployer le projet. Par exemple, vous pouvez importer une procédure stockée qui référence une table qui n'existe plus. Pour résoudre cette erreur, vous pouvez supprimer cette procédure stockée.

Vous devrez peut-être passer un certain temps à résoudre ce type d'erreurs en cas d'importation d'un schéma volumineux. Toutefois, les membres de l'équipe ne peuvent pas introduire d'erreurs supplémentaires de ce type lorsqu'ils mettent à jour le schéma dans Visual Studio Premium. Lorsqu'ils modifient et enregistrent des définitions d'objet, toutes les modifications sont validées afin que les membres de l'équipe puissent les résoudre immédiatement et éviter de les déployer dans une base de données active. Après avoir résolu les avertissements dans les définitions d'objet, vous devez envisager d'analyser également votre code de base de données pour rechercher les problèmes de conception, les problèmes d'attribution de noms et les problèmes de performance. Pour plus d'informations, consultez Analyse du code de base de données pour en améliorer la qualité.

Tâches courantes

Tâches courantes

Contenu de support

En savoir plus sur les projets de base de données et les limitations des projets partiels et composites : vous pouvez lire des informations sur les concepts de base de la gestion des modifications apportées aux schémas à l'aide de projets de base de données.

Apprendre en faisant : vous pouvez suivre une première procédure pas à pas pour vous familiariser avec le partitionnement d'un projet de base de données à l'aide de projets partiels ou de projets composites.

Placer un schéma de base de données existant sous contrôle de version : vous pouvez créer un projet, configurer ses paramètres et importer un schéma à l'aide de l'Assistant de projet de base de données. Vous pouvez également créer un projet vide si vous voulez importer le schéma ultérieurement ou si vous n'avez pas l'autorisation d'accéder à la base de données à partir de laquelle vous voulez importer le schéma. Après avoir importé le schéma, vous pouvez ajouter le projet au contrôle de version.

Partitionner un projet de base de données pour partager des définitions d'objet : vous pouvez exporter des définitions d'objet d'un projet de base de données et les réutiliser dans un autre projet. Même les membres de l'équipe qui peuvent accéder au projet dans lequel vous importez la définition du projet partiel ne peuvent pas modifier les objets importés. Par conséquent, vous pouvez contrôler les modifications apportées aux sous-ensembles de votre code de base de données.

Ajouter des références pour créer un projet composite : vous créez un projet composite en ajoutant des références à un projet de base de données mais sans spécifier de valeurs pour les variables de base de données et de serveur. Lorsque vous déployez un projet, vous déployez également les projets qu'il référence.

Utilisations et limitations des projets partiels

L'illustration suivante montre un scénario classique impliquant des projets partiels :

Utilisation de projets partiels dans Database Edition

Projets partiels dans Database Edition

Dans cet exemple, un projet contient deux jeux d'objets. Vous souhaitez qu'un autre développeur ou une autre équipe ajoute des procédures stockées au projet, mais vous voulez les empêcher d'apporter des modifications accidentelles aux autres objets. Pour atteindre cet objectif en utilisant des projets partiels, vous devez exécuter les étapes suivantes :

  1. Exportez les groupes d'objets, par schéma ou par type d'objet, dans les fichiers A.files et B.files.

  2. Créez un deuxième projet de base de données dans lequel l'autre développeur ou l'autre équipe créera les procédures stockées (parfois appelées sprocs).

  3. Importez les projets partiels exportés, A.files et B.files, dans le deuxième projet de base de données.

  4. Vous restreignez les autorisations de contrôle de code source aux objets inclus dans les projets partiels importés pour autoriser uniquement l'accès en lecture seule.

À ce stade, l'autre développeur ou l'autre équipe peut ajouter des objets, et générer et déployer son projet pour tester ses modifications.

Vous ne serez peut-être pas être en mesure d'importer le projet partiel (le fichier .files) dans un autre projet de base de données si votre base de données contient des objets portant des noms longs ou si le chemin d'accès dans lequel vous avez créé le projet de base de données est long. Vous pouvez éviter ces problèmes en tenant compte des suggestions suivantes :

  • Créez vos projets de base de données dans un dossier utilisant un nom de chemin d'accès plus court. Par exemple, « D:\MyProjects » peut être un meilleur choix que « C:\Documents and Settings\UserName\Mes documents\Visual Studio 2008\Projects ».

  • Évitez les noms très longs pour les objets de base de données. Les clés étrangères sont le type le plus commun d'objet pouvant avoir un nom long. Si le nom de votre clé étrangère est « FK_ReferencingTable_ReferencedTable_ReferencedColumn1_ReferencedColumn2 », des erreurs peuvent se produire lorsque vous essayez d'importer un projet partiel qui contient la définition de cette clé.

Utilisations et limitations des projets composites

L'illustration suivante montre un scénario classique impliquant des projets composites :

Utilisation de projets composites dans Database Edition

Projets composites dans Database Edition

Dans cet exemple, vous pouvez créer un projet de base de données qui contient les définitions de vos schémas. Créez ensuite un deuxième projet de base de données qui contient les définitions de vos tables et vues, et un troisième projet de base de données qui contient les définitions des procédures stockées. Le troisième projet (Projet de base de données C) a des références aux deux autres projets de base de données. Lorsque vous générez et déployez le troisième projet, vous déployez également automatiquement les autres projets.

Si vous utilisez des projets composites, vous devez être en mesure de générer et déployer chaque projet indépendamment. Vous ne pouvez pas avoir de dépendances circulaires entre les projets dans un projet composite. Vous pouvez utiliser des projets composites pour partitionner votre base de données par type d'objet. Par exemple, vous pouvez placer les schémas dans un projet, les tables et vues dans un autre, et les procédures stockées dans un troisième projet.

Scénarios associés