Structure de la base de données et contrôle de la source - meilleures pratiques

Question

Fondo

J'ai travaillé plusieurs années dans une entreprise où tous les objets de la base de données étaient stockés dans le contrôle de la source, un fichier par objet. Nous disposions d'une liste de tous les objets qui était mise à jour lorsque de nouveaux éléments étaient ajoutés (pour nous permettre d'exécuter les scripts dans l'ordre et de gérer les dépendances) et d'un scripts VB qui s'exécutait pour créer un grand scripts destiné à être exécuté contre la base de données.

Toutes les tables ont été "créées si elles n'existent pas" et toutes les SP, etc. ont été supprimées et recréées.

Jusqu'à présent, je travaille dans un endroit où la base de données est la base principale et où il n'y a pas de contrôle de la source pour les objets de la base de données, mais nous utilisons les outils de redgate pour mettre à jour notre base de données de production (SQL compare), ce qui est très pratique et nécessite peu de travail.

Question

Comment gérez-vous les objets de la base de données ? J'aime les avoir sous contrôle de source (et, comme nous utilisons GIT, j'aimerais pouvoir gérer les conflits de fusion dans les scripts, plutôt que dans la base de données), mais je vais avoir du mal à dépasser la facilité d'utilisation de SQL compare pour mettre à jour la base de données.

Je ne veux pas vraiment que nous mettions à jour les scripts dans GIT et que nous utilisions ensuite SQL compare pour mettre à jour la base de données de production à partir de notre base de données DEV, car je préfère avoir "une seule version de la vérité", mais je ne veux pas vraiment me lancer dans la réécriture d'un logiciel personnalisé pour regrouper l'ensemble des scripts.

Je pense que Visual Studio Database Edition peut faire quelque chose de similaire, mais je ne suis pas sûr que nous ayons le budget pour cela.

Je suis sûr que cette question a déjà été posée à maintes reprises, mais je n'arrive pas à trouver une réponse qui semble correspondre à ce que je cherche. La question est similaire à celle-ci, mais pas tout à fait la même :

Quelles sont les meilleures pratiques pour les scripts de base de données sous contrôle de code ?

---

J'ai lancé une prime, car je souhaite recueillir quelques avis supplémentaires - les réponses ici sont bonnes, mais je pense qu'il devrait y avoir un moyen plus simple.

Merci pour toutes ces excellentes réponses - elles ont toutes leurs mérites, je vais donc prendre le vote le plus élevé, mais je vous remercie pour tous vos commentaires.

Answer 1

Jetez un coup d'œil à cette série de cinq articles sur les principes et les pratiques du contrôle des versions des bases de données (par K. Scott Allen) :

1. Trois règles pour le travail dans les bases de données
2. La ligne de base
3. Modifier scripts
4. Vues, procédures stockées et autres
5. Branchement et fusion

Les cinq parties sont importantes, mais l'idée de base est d'avoir une référence et de modifier ensuite les scripts (avec une table de version). La mise à jour de la base de données consiste à appliquer les changements scripts "au-dessus" de la version actuelle. Cette stratégie est très conviviale pour les VCS (pas de conflits).

Answer 2

Tous les objets de notre base de données sont contrôlés à l'aide de Visual Studio Database Edition (DBPro). Il s'agit d'un outil merveilleux qui contrôle la version de notre schéma, effectue des constructions, des validations, permet l'analyse du code, des comparaisons de schémas, des déploiements, des comparaisons de données, des remaniements, etc. Il a été conçu dès le départ pour être un système de gestion de base de données et de contrôle de version. Il a été conçu dès le départ pour être un système de gestion de base de données et de contrôle de version.

Il s'agit du blog de l'architecte principal de DBPro : cliquez ici

Answer 3

En supposant que vous utilisiez le cadre .net, jetez un coup d'œil à la section Migrateur Fluent ainsi que le Podcast Hearding Code qui parle du projet.
L'objectif principal, tel que je le conçois, est de coder facilement les migrations comme vous le faites pour votre codage normal, en utilisant une interface fluide et une approche agnostique de la base de données.

Il est construit sur le cadre .net et fonctionne avec un certain nombre de formats de bases de données, notamment SQL Server, SqlLite et MySQL.

L'avantage de cette approche est qu'elle vit avec le reste de votre code et peut donc être gérée par le SCM.

Ejemplo:

   [Migration(1)]   
   public class CreateProjectsTable : Migration   
   {   
       public void Up()   
       {   
          Create.Table("Projects")              
            .WithIdColumn()             
            .WithColumn("Name").AsString().NotNullable()                
            .WithColumn("Position").AsInt32().NotNullable()             
            .WithColumn("Done").AsBoolean().NotNullable();
       }  
       public void Down()  
       {  
           Database.RemoveTable("Projects");  
       }  
   }

Answer 4

Si vous utilisez déjà les outils de Red Gate, vous pouvez envisager d'utiliser SQL Source Control, qui fonctionne en parallèle avec SQL Compare et SQL Data Compare pour permettre à une version de la vérité d'exister dans le contrôle de la source. Il s'agit d'un accès anticipé pour le moment, mais la plupart des fonctionnalités sont là pour être testées. Vous pouvez le télécharger à partir de http://www.red-gate.com/Products/SQL_Source_Control/index.htm . Cependant, il ne prend en charge que SVN et TFS pour le moment. Avez-vous opté pour GIT ?

David (Chef de produit chez Red Gate)

Answer 5

Nous avons un système dans lequel la base de données est nominalement le maître - dans notre système de contrôle des sources, nous maintenons une séquence de scripts (fichiers .sql) de "changement de schéma", chacun d'entre eux étant responsable de l'annulation idempotente du changement et de son application. Chaque scripts est simplement numéroté, de sorte que nous avons 000.sql (qui crée la base de données et met en place les objets standard), 001.sql, etc.

Au cours du développement, un développeur écrit un script de changement de schéma et l'exécute sur la base de données de développement. Chaque modification doit ajouter une ligne dans un fichier dba.change_info contenant le numéro de la modification et une brève description. Pour annuler une modification, il suffit d'en exécuter la première section. Pour SQL Server, l'idempotence de la section de retour en arrière est gérée en examinant les sysobjets, etc. avant d'émettre les commandes DROP - de manière similaire aux constructions "drop ... if exists". Les modifications de schéma peuvent nécessiter la migration de données si un modèle est modifié plutôt que simplement ajouté, et sont également utilisées pour maintenir les données de référence.

Au cours du processus de publication, un administrateur de bases de données (nous sommes une petite entreprise, ce rôle est donc assumé par l'un des développeurs) applique les modifications du schéma de la version à la base de données de production entre l'arrêt de l'ancienne version des applications et le démarrage de celles qui ont été mises à jour.

Il s'agit d'un processus assez manuel, mais qui répond à des besoins tels que la migration de données d'un modèle à un autre : par exemple, l'extension d'un indicateur booléen à un ensemble d'options, ou la conversion d'une association plusieurs-à-un en plusieurs-à-plusieurs. De toute façon, ce n'est généralement pas quelque chose qui peut être généré avec de simples outils de comparaison de schémas. Cela permet également de séparer les rôles - bien qu'en pratique nous ayons tous un accès complet à la production, il y a suffisamment de découplage pour que le "DBA" puisse lire et réviser les fichiers .sql à appliquer dans la production.

En théorie, du moins, une base de données complète (ne contenant que des données de référence) pourrait être construite en exécutant simplement toutes les modifications de schéma dans l'ordre à partir de 000.sql. En pratique, nous ne procédons pas régulièrement ainsi, mais nous copions plutôt notre base de données de production sur dev et appliquons ensuite le changement scripts avant d'exécuter les tests de régression avant une version. Cela permet de tester les changements scripts eux-mêmes, mais n'est pratique qu'avec une base de données de production de taille moyenne.