J'ai essayé à la fois RedGate et le projet de base de données de Visual Studio et je préfère stocker la définition de base de données dans le projet de base de données. Dès que la base de données fait partie de la solution, vous pouvez utiliser votre fournisseur de contrôle de source préféré. La plupart ont une excellente intégration de Visual Studio.
Avec les outils SSDT, vous disposez de la «dernière version» de la définition de la base de données, ce qui vous permet de faire facilement des comparaisons de schéma et de générer des scripts de mise à niveau de schéma.
Cela dit, le schéma n'est généralement qu'une partie de l'équasion. Dans la vraie vie, il s'avère que les bases de données contiennent déjà beaucoup de données. Et mes utilisateurs ont tendance à être plutôt déçus lorsqu'ils le perdent.
Donc, dès que j'ai déployé la version 1.0, le besoin se fait sentir de maintenir les scripts de mise à niveau. Parfois, ceux-ci contiennent simplement des modifications de schéma, mais souvent, je dois créer des valeurs par défaut basées sur le contenu d'une autre table, je dois libérer une contrainte particulière jusqu'à ce que j'amorce les données, etc. Habituellement, la simple mise à niveau du schéma ne la coupe pas tout à fait. Ma préférence est d'avoir ces scripts de mise à niveau dans un dossier séparé dans le projet de base de données aussi. Celles-ci ressemblent généralement à une «mise à niveau de la version 1.0 vers la version 1.1».
Mes bases de données ont toujours une table de référence qui m'indique le numéro de version actuel, donc je peux bloquer les mises à niveau incompatibles. La première déclaration de mes scripts de mise à niveau vérifie la version actuelle et renfloue si elle est différente de ce qui est attendu.
Un autre avantage des projets de base de données est de pouvoir déployer différents ensembles de données basés sur le même schéma. J'ai différents jeux de données pour le développement, l'équipe AQ, le test d'acceptation des utilisateurs et les tests d'intégration automatisés. Étant donné qu'un projet de base de données ne peut avoir qu'un seul script de post-déploiement, l'astuce consiste à créer un nouveau projet de base de données qui référence le projet `` maître '' et à intégrer l'ensemble de données personnalisé aux processus de post-déploiement de ce projet.
Ce sont mes 2 cents, quel que soit le processus que vous montez, il doit avant tout vous convenir à vous et à votre équipe et, espérons-le, vous soutenir dans la plupart des tâches courantes.