Gestion des versions de la base de données SQL Server

08-06-2019
|

Question

Je souhaite que mes bases de données soient sous contrôle de version.Quelqu'un a-t-il des conseils ou des articles recommandés pour me lancer ?

Je voudrai toujours avoir au moins quelques données là-dedans (comme alunb mentionne :types d'utilisateurs et administrateurs).Je souhaiterai aussi souvent une grande collection de données de test générées pour les mesures de performances.

La solution

Martin Fowler a écrit mon article préféré sur le sujet, http://martinfowler.com/articles/evodb.html.J'ai choisi de ne pas placer les dumps de schéma sous contrôle de version car alunb et d'autres le suggèrent parce que je souhaite un moyen simple de mettre à niveau ma base de données de production.

Pour une application Web où j'aurai une seule instance de base de données de production, j'utilise deux techniques :

Scripts de mise à niveau de base de données

Une séquence de scripts de mise à niveau de base de données contenant le DDL nécessaire pour déplacer le schéma de la version N vers N+1.(Ceux-ci vont dans votre système de contrôle de version.) Une table _version_history_, quelque chose comme

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

obtient une nouvelle entrée à chaque exécution d'un script de mise à niveau correspondant à la nouvelle version.

Cela garantit qu'il est facile de voir quelle version du schéma de base de données existe et que les scripts de mise à niveau de base de données ne sont exécutés qu'une seule fois.Encore une fois, ce sont pas dumps de base de données.Au contraire, chaque script représente le changements nécessaire de passer d'une version à l'autre.Il s'agit du script que vous appliquez à votre base de données de production pour la "mettre à niveau".

Synchronisation du bac à sable des développeurs

Un script pour sauvegarder, nettoyer et réduire une base de données de production.Exécutez-le après chaque mise à niveau vers la base de données de production.
Un script pour restaurer (et modifier, si nécessaire) la sauvegarde sur le poste de travail d'un développeur.Chaque développeur exécute ce script après chaque mise à niveau vers la base de données de production.

Une mise en garde :Mes tests automatisés s'exécutent sur une base de données dont le schéma est correct mais vide, ce conseil ne répondra donc pas parfaitement à vos besoins.

Autres conseils

Le produit SQL Compare de Red Gate vous permet non seulement d'effectuer des comparaisons au niveau des objets et de générer des scripts de modification à partir de celles-ci, mais il vous permet également d'exporter vos objets de base de données dans une hiérarchie de dossiers organisée par type d'objet, avec une création [objectname].sql. script par objet dans ces répertoires.La hiérarchie des types d'objets est la suivante :

\Les fonctions
\Sécurité
\Sécurité ôles
\Sécurité\Schémas
\Sécurité\Utilisateurs
\Procédures stockées
\Les tables

Si vous sauvegardez vos scripts dans le même répertoire racine après avoir apporté des modifications, vous pouvez l'utiliser pour mettre à jour votre référentiel SVN et conserver un historique en cours de chaque objet individuellement.

C’est l’un des « problèmes difficiles » liés au développement.Pour autant que je sache, il n’existe pas de solutions parfaites.

Si vous avez uniquement besoin de stocker la structure de la base de données et non les données, vous pouvez exporter la base de données sous forme de requêtes SQL.(dans Enterprise Manager :Faites un clic droit sur la base de données -> Générer un script SQL.Je recommande de définir "créer un fichier par objet" dans l'onglet options). Vous pouvez ensuite valider ces fichiers texte dans svn et utiliser les fonctions de comparaison et de journalisation de svn.

J'ai ceci lié avec un script Batch qui prend quelques paramètres et configure la base de données.J'ai également ajouté des requêtes supplémentaires qui saisissent des données par défaut telles que les types d'utilisateurs et l'utilisateur administrateur.(Si vous voulez plus d'informations à ce sujet, postez quelque chose et je pourrai mettre le script dans un endroit accessible)

Si vous devez également conserver toutes les données, je vous recommande de conserver une sauvegarde de la base de données et d'utiliser Redgate (http://www.red-gate.com/) produits pour faire les comparaisons.Ils ne sont pas bon marché, mais ils valent chaque centime.

Tout d’abord, vous devez choisir le système de contrôle de version qui vous convient :

Système de contrôle de version centralisé : un système standard dans lequel les utilisateurs extraient/enregistrent avant/après avoir travaillé sur des fichiers, et les fichiers sont conservés sur un seul serveur central.
Système de contrôle de version distribuée - Un système où le référentiel est cloné, et chaque clone est en fait la sauvegarde complète du référentiel, donc si un serveur s'écrase, un référentiel cloné peut être utilisé pour le restaurer après avoir choisi le bon système pour vos besoins , vous devrez configurer le référentiel qui est le cœur de chaque système de contrôle de version, tout cela est expliqué dans l'article suivant: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/

Après avoir configuré un référentiel et, dans le cas d'un système de contrôle de version central, un dossier de travail, vous pouvez lire Cet article.Il montre comment configurer le contrôle de source dans un environnement de développement en utilisant :

SQL Server Management Studio via le fournisseur MSSCCI,
Outils de données Visual Studio et SQL Server
Un outil tiers ApexSQL Source Control

Chez Red Gate, nous proposons un outil, Contrôle de source SQL, qui utilise la technologie SQL Compare pour lier votre base de données à un référentiel TFS ou SVN.Cet outil s'intègre à SSMS et vous permet de travailler comme vous le feriez normalement, sauf qu'il vous permet désormais de valider les objets.

Pour une approche basée sur les migrations (plus adaptée aux déploiements automatisés), nous proposons Automatisation des modifications SQL (anciennement appelé ReadyRoll), qui crée et gère un ensemble de scripts incrémentiels en tant que projet Visual Studio.

Dans SQL Source Control, il est possible de spécifier des tables de données statiques.Ceux-ci sont stockés dans le contrôle de code source sous forme d'instructions INSERT.

Si vous parlez de données de test, nous vous recommandons soit de générer des données de test avec un outil ou via un script de post-déploiement que vous définissez, soit de simplement restaurer une sauvegarde de production dans l'environnement de développement.

Vous voudrez peut-être consulter Liquibase (http://www.liquibase.org/).Même si vous n'utilisez pas l'outil lui-même, il gère assez bien les concepts de gestion des modifications de base de données ou de refactorisation.

+1 pour tous ceux qui ont recommandé les outils RedGate, avec une recommandation supplémentaire et une mise en garde.

SqlCompare dispose également d'une API correctement documentée :Ainsi, vous pouvez, par exemple, écrire une application console qui synchronise votre dossier de scripts contrôlé par la source avec une base de données de tests d'intégration CI lors de l'enregistrement, de sorte que lorsque quelqu'un enregistre une modification du schéma à partir de son dossier de scripts, elle est automatiquement déployée avec l'application correspondante. changement de code.Cela permet de combler l'écart avec les développeurs qui oublient de propager les modifications dans leur base de données locale jusqu'à une base de données de développement partagée (environ la moitié d'entre nous, je pense :)).

Une mise en garde est qu'avec une solution scriptée ou autre, les outils RedGate sont suffisamment fluides pour qu'il soit facile d'oublier les réalités SQL sous-jacentes à l'abstraction.Si vous renommez toutes les colonnes d'une table, SqlCompare n'a aucun moyen de mapper les anciennes colonnes aux nouvelles colonnes et supprimera toutes les données de la table.Cela générera des avertissements, mais j'ai vu des gens cliquer au-delà de cela.Il y a un point général qui mérite d'être souligné, je pense, que vous ne pouvez automatiser la gestion des versions et la mise à niveau de la base de données que jusqu'à présent - les abstractions sont très fuyantes.

Nous utilisons DBGhost pour gérer notre base de données SQL.Ensuite, vous placez vos scripts pour créer une nouvelle base de données dans votre contrôle de version, et cela créera une nouvelle base de données ou mettra à niveau toute base de données existante vers le schéma dans le contrôle de version.De cette façon, vous n'avez pas à vous soucier de la création de scripts de modification (bien que vous puissiez toujours le faire, si par exemple vous souhaitez modifier le type de données d'une colonne et devez convertir des données).

Avec VS 2010, utilisez le projet Database.

Scriptez votre base de données
Apporter des modifications aux scripts ou directement sur votre serveur DB
Synchroniser à l'aide de données> Schéma Comparez

C'est une solution de gestion de versions de base de données parfaite et facilite la synchronisation des bases de données.

C'est une bonne approche pour enregistrer les scripts de base de données dans le contrôle de version avec des scripts de modification afin de pouvoir mettre à niveau n'importe quelle base de données dont vous disposez.Vous souhaiterez peut-être également enregistrer des schémas pour différentes versions afin de pouvoir créer une base de données complète sans avoir à appliquer tous les scripts de modification.La gestion des scripts doit être automatisée afin que vous n'ayez pas à effectuer de travail manuel.

Je pense qu'il est important d'avoir une base de données distincte pour chaque développeur et de ne pas utiliser de base de données partagée.De cette façon, les développeurs peuvent créer des cas de test et des phases de développement indépendamment des autres développeurs.

L'outil d'automatisation doit disposer de moyens de gestion des métadonnées de la base de données, qui indiquent quelles bases de données se trouvent dans quel état de développement et quelles tables contiennent des données dont la version est contrôlable, etc.

Vous pouvez également envisager une solution de migration.Ceux-ci vous permettent de spécifier votre schéma de base de données en code C# et de monter et descendre la version de votre base de données à l'aide de MSBuild.

J'utilise actuellement DbUp, et ça marche bien.

Vous n'avez mentionné aucun détail sur votre environnement cible ou vos contraintes, cela peut donc ne pas être entièrement applicable...mais si vous cherchez un moyen de suivre efficacement un schéma de base de données en évolution et que vous n'êtes pas opposé à l'idée d'utiliser Ruby, les migrations d'ActiveRecord sont faites pour vous.

Les migrations définissent par programmation les transformations de bases de données à l'aide d'un Ruby DSL ;chaque transformation peut être appliquée ou (généralement) annulée, vous permettant de passer à une version différente de votre schéma de base de données à tout moment.Le fichier définissant ces transformations peut être archivé dans le contrôle de version comme n'importe quel autre morceau de code source.

Parce que les migrations font partie Enregistrement actif, ils sont généralement utilisés dans les applications Rails full-stack ;cependant, vous pouvez utiliser ActiveRecord indépendamment de Rails avec un minimum d'effort.Voir ici pour un traitement plus détaillé de l'utilisation des migrations d'AR en dehors de Rails.

Chaque base de données doit être sous contrôle du code source.Ce qui manque, c'est un outil permettant de scripter automatiquement tous les objets de base de données - et les "données de configuration" - dans un fichier, qui peuvent ensuite être ajoutés à n'importe quel système de contrôle de source.Si vous utilisez SQL Server, ma solution est ici : http://dbsourcetools.codeplex.com/ .Amusez-vous.-Nathan.

C'est simple.

Lorsque le projet de base est prêt, vous devez créer un script de base de données complet.Ce script est validé sur SVN.C'est la première version.
Après cela, tous les développeurs créent des scripts de modification (ALTER..., nouvelles tables, sprocs, etc.).
Lorsque vous avez besoin de la version actuelle, vous devez exécuter tous les nouveaux scripts de modification.
Lorsque l'application est mise en production, vous revenez à 1 (mais ce sera alors une version successive bien sûr).

Nant vous aidera à exécuter ces scripts de modification.:)

Et rappelez-vous.Tout fonctionne bien quand il y a de la discipline.Chaque fois qu'une modification de la base de données est validée, les fonctions correspondantes dans le code sont également validées.

Si vous avez une petite base de données et que vous souhaitez versionner l'ensemble, ce script batch pourrait aider.Il détache, compresse et archive un fichier MDF de base de données MSSQL dans Subversion.

Si vous souhaitez principalement versionner votre schéma et disposer d'une petite quantité de données de référence, vous pouvez éventuellement utiliser Migrations subsoniques pour gérer ça.L’avantage est que vous pouvez facilement migrer vers une version supérieure ou inférieure.

Pour rendre le vidage vers un système de contrôle de code source un peu plus rapide, vous pouvez voir quels objets ont changé depuis la dernière fois en utilisant les informations de version dans sysobjects.

Installation: Créez une table dans chaque base de données que vous souhaitez vérifier de manière incrémentielle pour contenir les informations de version de la dernière fois que vous l'avez vérifiée (vide lors de la première exécution).Effacez ce tableau si vous souhaitez réanalyser l'ensemble de votre structure de données.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Mode de fonctionnement normal : Vous pouvez prendre les résultats de ce SQL, générer des scripts SQL uniquement pour ceux qui vous intéressent et les placer dans un contrôle de code source de votre choix.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Note: Si vous utilisez un classement non standard dans l'une de vos bases de données, vous devrez le remplacer /* COLLATE */ avec le classement de votre base de données.c'est à dire. COLLATE Latin1_General_CI_AI

Étant donné que notre application doit fonctionner sur plusieurs SGBDR, nous stockons notre définition de schéma dans le contrôle de version à l'aide de la base de données neutre. Couple (XML).Nous contrôlons également la version des données de référence de notre base de données au format XML comme suit (où « Relation » est l'une des tables de référence) :

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Nous utilisons ensuite des outils développés en interne pour générer les scripts de mise à niveau du schéma et de mise à niveau des données de référence nécessaires pour passer de la version X de la base de données à la version X + 1.

Nous ne stockons pas le schéma de la base de données, nous stockons les modifications apportées à la base de données.Ce que nous faisons, c'est stocker les modifications du schéma afin de créer un script de modification pour n'importe quelle version de la base de données et de l'appliquer aux bases de données de nos clients.J'ai écrit une application utilitaire de base de données qui est distribuée avec notre application principale et qui peut lire ce script et savoir quelles mises à jour doivent être appliquées.Il dispose également de suffisamment d’intelligence pour actualiser les vues et les procédures stockées selon les besoins.

Nous avons eu besoin de versionner notre base de données SQL après avoir migré vers une plate-forme x64 et notre ancienne version a rompu avec la migration.Nous avons écrit une application C# qui utilisait SQLDMO pour mapper tous les objets SQL dans un dossier :

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

L'application comparerait alors la version nouvellement écrite à la version stockée dans SVN et s'il y avait des différences, elle mettrait à jour SVN.Nous avons déterminé qu'exécuter le processus une fois par nuit était suffisant puisque nous n'apportons pas beaucoup de modifications à SQL.Il nous permet de suivre les modifications apportées à tous les objets qui nous intéressent et de reconstruire notre schéma complet en cas de problème grave.

J'ai écrit cette application il y a quelque temps, http://sqlschemasourcectrl.codeplex.com/ qui analysera vos bases de données MSFT SQL aussi souvent que vous le souhaitez et videra automatiquement vos objets (tables, vues, processus, fonctions, paramètres SQL) dans SVN.Fonctionne à merveille.Je l'utilise avec Unfuddle (qui me permet de recevoir des alertes lors des checkins)

La solution typique consiste à vider la base de données si nécessaire et à sauvegarder ces fichiers.

En fonction de votre plateforme de développement, des plugins open source peuvent être disponibles.Lancer votre propre code pour le faire est généralement assez trivial.

Note:Vous souhaiterez peut-être sauvegarder le dump de la base de données au lieu de le placer dans le contrôle de version.Les fichiers peuvent devenir très rapides dans le contrôle de version et ralentir l'ensemble de votre système de contrôle de source (je me souviens d'une histoire d'horreur CVS en ce moment).

Nous venons de commencer à utiliser Team Foundation Server.Si votre base de données est de taille moyenne, Visual Studio propose de belles intégrations de projets avec une comparaison intégrée, une comparaison de données, des outils de refactorisation de base de données, un cadre de test de base de données et même des outils de génération de données.

Mais ce modèle ne s'adapte pas très bien aux bases de données très volumineuses ou tierces (qui chiffrent les objets).Nous avons donc décidé de stocker uniquement nos objets personnalisés.Le serveur Visual Studio / Team Foundation fonctionne très bien pour cela.

Arch chef de la base de données TFS.Blog

Site MSTFS

Je suis d'accord avec la réponse d'ESV et c'est précisément pour cette raison que j'ai commencé un petit projet il y a quelque temps pour aider à maintenir les mises à jour de la base de données dans un fichier très simple qui pourrait ensuite être conservé dans le code source long.Il permet des mises à jour faciles aux développeurs ainsi qu'à l'UAT et à la production.L'outil ne fonctionne que sur SQL Server et MySql.

Quelques fonctionnalités du projet :

Permet les modifications de schéma
Permet la population de l'arbre de valeurs
Permet des insertions de données de test séparées, par exemple.UAT
Permet l'option de restauration (non automatisée)
Maintient la prise en charge de SQL Server et Mysql
A la possibilité d'importer votre base de données existante dans le contrôle de version avec une simple commande (serveur SQL uniquement...je travaille toujours sur MySQL)

Le code est hébergé sur Google Code.Veuillez consulter le code Google pour plus d'informations

http://code.google.com/p/databaseversioncontrol/

Il y a quelque temps, j'ai trouvé un module VB bas qui utilisait des objets DMO et VSS pour obtenir une base de données entière scriptée et insérée dans VSS.Je l'ai transformé en script VB et je l'ai posté ici.Vous pouvez facilement supprimer les appels VSS et utiliser les éléments DMO pour générer tous les scripts, puis appeler SVN à partir du même fichier batch qui appelle le VBScript pour les archiver ?

Dave J.

J'utilise également une version de la base de données stockée via la famille de procédures de propriétés étendues de la base de données.Mon application dispose de scripts pour chaque étape de version (c.-à-d.passer de 1,1 à 1,2).Une fois déployé, il examine la version actuelle, puis exécute les scripts un par un jusqu'à ce qu'il atteigne la dernière version de l'application.Il n'existe aucun script qui ait la version "finale" directe, même le déploiement sur une base de données propre effectue le déploiement via une série d'étapes de mise à niveau.

Maintenant, ce que j'aime ajouter, c'est que j'ai vu il y a deux jours une présentation sur le campus MS concernant la nouvelle et prochaine édition de VS DB.La présentation était spécifiquement axée sur ce sujet et j'ai été époustouflé.Vous devriez absolument y jeter un coup d'œil, les nouvelles fonctionnalités sont axées sur le maintien de la définition du schéma dans les scripts T-SQL (CREATE), un moteur delta d'exécution pour comparer le schéma de déploiement avec le schéma défini et effectuer les ALTER delta et l'intégration avec l'intégration du code source, jusqu'à et y compris l'intégration continue MSBUILD pour les abandons de build automatisés.Le dépôt contiendra un nouveau type de fichier, les fichiers .dbschema, qui pourront être transférés sur le site de déploiement et un outil de ligne de commande pourra effectuer les « deltas » réels et exécuter le déploiement.J'ai un article de blog sur ce sujet avec des liens vers les téléchargements VSDE, vous devriez les consulter : http://rusanu.com/2009/05/15/version-control-and-your-database/

C’est une question très ancienne, mais nombreux sont ceux qui tentent de la résoudre dès maintenant.Tout ce qu'ils ont à faire est de rechercher des projets de base de données Visual Studio.Sans cela, tout développement de base de données semble très faible.De l’organisation du code au déploiement en passant par le versioning, cela simplifie tout.

D'après mon expérience, la solution est double :

Vous devez gérer les modifications apportées à la base de données de développement par plusieurs développeurs au cours du développement.
Vous devez gérer les mises à niveau des bases de données sur les sites des clients.

Afin de gérer le n°1, vous aurez besoin d'un outil de comparaison/fusion de base de données puissant.Le meilleur outil doit être capable d’effectuer autant que possible une fusion automatique tout en vous permettant de résoudre manuellement les conflits non gérés.

L'outil parfait doit gérer les opérations de fusion en utilisant un algorithme de fusion à 3 voies qui prend en compte les modifications apportées à la base de données THEIRS et à la base de données MINE, par rapport à la base de données BASE.

J'ai écrit un outil commercial qui fournit une prise en charge de la fusion manuelle pour les bases de données SQLite et j'ajoute actuellement la prise en charge de l'algorithme de fusion à trois voies pour SQLite.Vérifiez-le sur http://www.sqlitecompare.com

Afin de gérer le n°2, vous aurez besoin d’un cadre de mise à niveau en place.

L'idée de base est de développer un cadre de mise à niveau automatique qui sait comment mettre à niveau un schéma SQL existant vers le schéma SQL le plus récent et peut créer un chemin de mise à niveau pour chaque installation de base de données existante.

Découvrez mon article sur le sujet dans http://www.codeproject.com/KB/database/sqlite_upgrade.aspx pour avoir une idée générale de ce dont je parle.

Bonne chance

Liron Lévi

Découvrez DBGhost http://www.innovartis.co.uk/.Je l'utilise de manière automatisée depuis 2 ans maintenant et ça marche très bien.Cela permet à nos builds de base de données de se produire un peu comme une build Java ou C, à l'exception de la base de données.Vous savez ce que je veux dire.

Je suggérerais d'utiliser des outils de comparaison pour improviser un système de contrôle de version pour votre base de données.Une bonne alternative est Comparaison de schémas xSQL et Comparaison de données xSQL.

Désormais, si votre objectif est d'avoir uniquement le schéma de la base de données sous contrôle de version, vous pouvez simplement utiliser xSQL Schema Compare pour générer des instantanés xSQL du schéma et ajouter ces fichiers dans votre contrôle de version.Ensuite, pour revenir ou mettre à jour vers une version spécifique, comparez simplement la version actuelle de la base de données avec l'instantané de la version de destination.

Hélas, si vous souhaitez également que les données soient sous contrôle de version, vous pouvez utiliser xSQL Data Compare pour générer des scripts de modification pour votre base de données et ajouter les fichiers .sql dans votre contrôle de version.Vous pouvez ensuite exécuter ces scripts pour revenir/mettre à jour vers la version de votre choix.Gardez à l'esprit que pour la fonctionnalité « revenir », vous devez générer des scripts de modification qui, une fois exécutés, rendront la version 3 identique à la version 2 et pour la fonctionnalité « mettre à jour », vous devez générer des scripts de modification qui font le contraire.

Enfin, avec quelques compétences de base en programmation par lots, vous pouvez automatiser l'ensemble du processus en utilisant les versions en ligne de commande de xSQL Schema Compare et xSQL Data Compare.

Clause de non-responsabilité:Je suis affilié à xSQL.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow