web-dev-qa-db-fra.com

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

Contexte

Je travaillais depuis plusieurs années dans une entreprise où tous les objets de base de données étaient stockés dans le contrôle de source, un fichier par objet. Nous avions une liste de tous les objets conservés 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 un script VB exécuté pour créer un gros script à exécuter contre la base de données. 

Toutes les tables étaient 'créer sinon existantes' et tous les SP, etc. étaient supprimés et recréés.

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

Question

Comment gérez-vous vos objets de base de données? J'aime les avoir sous contrôle de code 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 être pressé de 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, puis que nous utilisions SQL comparatif pour mettre à jour la base de données de production à partir de notre base de données DEV, car je préférerais avoir «une version de la vérité», mais je ne veux pas vraiment commencez à réécrire un logiciel sur mesure pour regrouper l’ensemble des scripts.

Je pense que Visual Studio Edition de base de données peut faire quelque chose de similaire à cela, mais je ne suis pas sûr si nous aurons le budget pour cela.

Je suis sûr que cela a été demandé à mort, mais je ne trouve rien qui semble avoir la réponse que je cherche. Semblable à ceci, mais pas tout à fait la même chose:

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

Commencé une prime, car je suis intéressé par la sollicitation de quelques opinions supplémentaires - les réponses ici sont bonnes, mais j'estime qu'il devrait y avoir vraiment un moyen plus facile.

Merci pour toutes les bonnes réponses - toutes ont leurs mérites, donc je vais prendre le vote le plus élevé, mais applaudissons pour toutes les contributions.

databaseversion-control
44
Paddy

Tous nos objets de base de données sont sous contrôle de code source à l'aide de Visual Studio Database Edition (DBPro). C’est un outil formidable qui permet à la version de contrôler notre schéma, de créer, de valider, d’analyser le code, de comparer les schémas, de déployer, de comparer les données, de refactoriser, etc. Hautement recommandé.

Ceci est le site de blog de l’architecte principal de DBPro: cliquez ici

13
Randy Minder

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

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

Les cinq parties sont importantes, mais l’idée est essentiellement de disposer d’une base de référence, puis de modifier les scripts (avec un tableau de versions). Mettre à jour la base de données signifie appliquer des scripts de changement "au-dessus" de la version actuelle. Et cette stratégie est très conviviale avec VCS (pas de conflit).

21
Pascal Thivent

À l'aide d'un complément SSMS tiers ApexSQL Source Control , les objets de base de données peuvent être automatiquement scriptés et transférés vers un référentiel Git distant, voire vers un référentiel local cloné, si vous préférez utiliser le référentiel local.

Le contrôle de code source ApexSQL supporte immédiatement le système de contrôle de code source Git. Cela signifie que vous n’avez besoin d’aucun client Git supplémentaire. En outre, les fonctions de branchement et de fusion sont intégrées et disponibles via l'interface utilisateur complémentaire.

9
Lewis_E

En supposant que vous utilisiez le framework .net, jetez un coup d'œil au Fluent Migrator ainsi qu'au Hearding Code Podcast qui parle du projet.
À mon avis, le principal objectif est de coder facilement les migrations tout en effectuant votre codage normal à l'aide d'une interface fluide utilisant une approche agnostique de base de données. 

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

L’avantage de cette approche est qu’il habite avec le reste de votre code et peut donc être géré par SCM.

Exemple:

   [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");  
       }  
   }
4
Nathan Fisher

Si vous utilisez déjà des outils Red Gate, vous pouvez utiliser le contrôle de source SQL, qui fonctionne côte à côte avec SQL Compare et SQL Data Compare pour permettre à une version de la vérité d'exister dans le contrôle de source. C'est un accès anticipé pour le moment, mais la plupart des fonctionnalités sont là pour être essayées. Vous pouvez télécharger ceci à partir de http://www.red-gate.com/Products/SQL_Source_Control/index.htm . Cependant, il ne supporte que SVN et TFS pour le moment. Avez-vous normalisé sur GIT?

David (chef de produit chez Red Gate)

3
David Atkinson

Nous avons un système où la base de données est nominalement le maître dans notre système de contrôle de code source, nous maintenons une séquence de scripts de "modification de schéma" (fichiers .sql), chacun d'entre eux étant responsable de l'annulation de la modification, puis de son application. Chaque script est simplement numéroté, nous avons donc 000.sql (qui crée la base de données et configure les objets standard), 001.sql, etc. 

Au cours du développement, un développeur écrit un script de modification de schéma et l'exécute sur la base de développement. Chaque modification est nécessaire pour ajouter une ligne dans une table dba.change_info, contenant le numéro de modification et une brève description. Pour annuler une modification, il suffit de lancer la première partie de celle-ci. Pour SQL Server, l'idempotence de la section d'annulation est gérée en examinant sysobjects, etc. avant d'émettre des commandes DROP, similaires aux constructions "drop ... if exist". Les modifications de schéma peuvent nécessiter une migration des données si un modèle est modifié plutôt que simplement ajouté et est également utilisé pour gérer les données de référence.

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

Il s’agit d’un processus plutôt manuel, mais qui répond à des exigences telles que la migration des données d’un modèle à un autre: par exemple, élargir un drapeau booléen à un ensemble d'options ou convertir une association plusieurs-à-un en plusieurs-à-plusieurs. Ce n'est généralement pas quelque chose qui peut être généré avec de simples outils de comparaison de schéma. Cela permet également la séparation des rôles - bien que, dans la pratique, nous ayons tous un accès complet à la production, le découplage y est suffisant pour que le "DBA" puisse lire et réviser les fichiers .sql à appliquer en production.

En théorie, au moins, une base de données complète (contenant uniquement des données de référence) pourrait être construite en exécutant simplement toutes les modifications de schéma dans l'ordre suivant pour 000.sql. En pratique, nous ne le faisons pas régulièrement, mais copions plutôt notre base de production pour dev, puis appliquons les scripts de changement avant d'exécuter des tests de régression avant une publication. Ceci sert à tester les scripts de changement eux-mêmes, mais n'est pratique qu'avec une base de données de production de taille moyenne.

2
araqnid

Je ne connais pas très bien la boîte à outils RedGate, mais si elle ressemble à dbGhost , il doit exister un utilitaire vous permettant de scripter les objets de base de données dans les fichiers un par objet. Dans ce cas, je suggérerais de suivre:

  • ajouter un travail quotidien (ou une partie d'un travail de construction) pour procéder à l'ingénierie inverse de la base de donnéesDEVdans la structure de répertoires
  • puis comparez-le à ce que vous avez dans le référentiel (au moyen d'un simple diff), et fondamentalementÉCHOUEle travail de construction et signalez la variable diff, le cas échéant. Cela indiquera que la structure de la base de données DEV a changé et n’est pas reflétée dans le contrôle de source,
  • ce qui indiquera au développeur d'ajouter les modifications au contrôle de source (utilisez même le fichier rapporté .diff pour cela)

Si vous avez beaucoup de bases de données DEV (une par utilisateur ou par branche de développement) et que cela est trop lourd, une meilleure combinaison serait probablement de le faire sur la version STAGE (TEST juste avant la version) de la base de données. PROD dans le référentiel et ne le mettrait à jour à partir de STAGE que pendant la phase de test préliminaire, où vous vous assurerez que vos modifications de schéma sont également dans le référentiel.

De cette manière, les développeurs peuvent toujours travailler de la manière habituelle: modifiez d’abord le schéma de la base de données DEV, et espérons que vous obtiendrez l’équilibre entre les flexibility et one truth souhaités.

Dans mon équipe, nous ajoutons des modifications à VCS dès que nous modifions la base de données DEV, mais nous avons toujours cette tâche pour comparer le schéma entre différentes bases de données (DEV, STAGE et PROD). En gros, nous suivons ce que j’avais déjà répondu dans Comment devez-vous construire votre base de données à partir du contrôle de source? .

2
van

Au travail, nous utilisons beaucoup un outil puissant intégré à ActiveRecord (qui est l’ORM par défaut fourni avec le framework Rails web appelé Migrations .

Une migration de base ressemblerait à ceci:

class AddSystems < ActiveRecord::Migration
  def self.up
    create_table :systems do |t|
      t.string  :name
      t.string  :label
      t.text    :value
      t.string  :type
      t.integer :position, :default => 1
      t.timestamps
    end
  end

  def self.down
    drop_table :systems
  end
end

Une migration est créée pour chaque modification de base de données et elles sont créées dans un ordre séquentiel par horodatage. Vous pouvez exécuter des méthodes prédéfinies pour exécuter ces migrations dans le bon ordre afin que votre base de données puisse toujours être créée et/ou restaurée. Certaines des fonctions sont ci-dessous:

rake db:migrate #run all outstanding migrations
rake db:rollback #roll back the last run migration
rake db:seed #fill the database with your seed data

Les migrations ont des méthodes pour créer des tables, les supprimer, les mettre à jour, ajouter des index, etc. La suite complète. Les migrations ajoutent également automatiquement une colonne id et la section t.timestamps génère automatiquement un champ "created_at" et un champ "updated_at".

La plupart des langues ont des fonctionnalités ORM telles que celles-ci, et permettent de maintenir la base de données dans un état semblable à un code, ce qui est facile à comprendre pour les développeurs et assez simple à utiliser et à maintenir pour les administrateurs de base de données.

1
Mike Trpcic

Il y a un outil spécial pour cette chose exacte. Cela s'appelle Wizardby :

... infrastructure d'intégration de base de données et de migration de schéma en continu

Wizardby Workflow http://octalforty-wizardby.googlecode.com/svn/trunk/docs/img/database_versioning_with_wizardby.png

0
Anton Gogolev

Je gère actuellement une conception de base de données dans un outil de modélisation (DeZine pour bases de données) et la stocke sous contrôle de source. Dans ma conception de table, j'ajoute une table avec deux lignes qui portent le numéro de version du schéma et des données de référence. Cette dernière est mise à jour chaque fois que la base de données est modifiée/publiée (les utilisateurs n'accèdent pas à cette table).

Les données de référence sont conservées dans une feuille de calcul Excel (également sous contrôle de source) pouvant générer un script SQL d'instructions INSERT pour remplir de nouvelles bases de données.

Lorsqu'une nouvelle version est requise, le script de schéma, le script de données de référence et un package d'installation sont envoyés. Le package d'installation renomme l'ancienne base de données, crée une nouvelle base de données à partir du script et importe les nouvelles données de référence (éventuellement modifiées). Les données de l'utilisateur sont ensuite copiées de l'ancienne base de données (renommée) vers la nouvelle.

Cela présente l’avantage de pouvoir, en cas de problème, revenir à la base de données originale, car elle n’a pas été modifiée.

0
Tony