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

Je veux toujours avoir au moins quelques données dedans (comme le mentionne alumb : types d'utilisateurs et administrateurs). Je veux aussi souvent une grande collection de données de test générées pour les mesures de performance.

Martin Fowler a écrit mon article préféré sur le sujet, http://martinfowler.com/articles/evodb.html . Je choisis de ne pas placer les vidages de schéma sous le contrôle de version comme alumb et d'autres le suggèrent parce que je veux un moyen facile 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 la base de données

Scripts de mise à niveau de la base de données de séquence 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 qui correspond à 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 la base de données ne sont exécutés qu'une seule fois. Encore une fois, ce ne sont pas des vidages de base de données. Au contraire, chaque script représente les changements nécessaires pour passer d'une version à la suivante. Ce sont les scripts que vous appliquez à votre base de données de production pour la "mettre à niveau".

Développeur Sandbox Synchronization

1. Un script pour sauvegarder, nettoyer et réduire une base de données de production. Exécutez cela après chaque mise à niveau vers la base de données de production.
2. Un script pour restaurer (et modifier, si nécessaire) la sauvegarde sur la station 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 correcte mais vide de schéma, donc ce conseil ne conviendra pas parfaitement à vos besoins.

Le produit SQL Compare de Red Gate vous permet non seulement de faire des comparaisons au niveau des objets et de générer des scripts de modification à partir de cela, 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 [objectname] .sql creation script par objet dans ces répertoires. La hiérarchie de type d'objet est la suivante:

\ Fonctions
\ Sécurité
\ Sécurité \ Rôles
\ Sécurité \ Schémas
\ Sécurité \ Utilisateurs
\ Procédures stockées
\ 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 de chaque objet individuellement.

C'est l'un des "problèmes difficiles" qui entourent le développement. Pour autant que je sache, il n'y a pas de solutions parfaites.

Si vous avez seulement besoin de stocker la structure de la base de données et non les données, vous pouvez exporter la base de données en tant que requêtes SQL. (dans Enterprise Manager: cliquez avec le bouton droit sur la base de données -> Générer un script SQL. Je recommande de définir le "créer un fichier par objet" dans l'onglet Options) Vous pouvez ensuite valider ces fichiers texte dans svn et utiliser les fonctions de diff et de journalisation de svn.

J'ai ce lien avec un script Batch qui prend quelques paramètres et configure la base de données. J'ai également ajouté quelques requêtes supplémentaires qui saisissent des données par défaut comme les types d'utilisateurs et l'utilisateur administrateur. (Si vous voulez plus d'informations à ce sujet, postez quelque chose et je peux 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 les produits Redgate ( http://www.red-gate.com/ ) pour effectuer 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 où les utilisateurs récupèrent / archivent 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é - 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 tombe en panne, n'importe quel 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 au 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 code source dans un environnement de développement en utilisant:

• SQL Server Management Studio via le fournisseur MSSCCI,

• Visual Studio et SQL Server Data Tools

• Un outil tiers ApexSQL Source Control

Chez Red Gate, nous proposons un outil, SQL Source Control , qui utilise la technologie SQL Compare pour relier votre base de données à un référentiel TFS ou SVN. Cet outil s'intègre dans 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 SQL Change Automation (anciennement 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. Celles-ci sont stockées dans le contrôle de code source sous forme d'instructions INSERT.

Si vous parlez de données de test, nous vous recommandons de générer des données de test avec un outil ou via un script de post-déploiement que vous définissez, ou 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 a également une API décemment documentée: 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 test d'intégration CI lors de l'archivage, de sorte que lorsque quelqu'un enregistre une modification du schéma à partir de son dossier de scripts il est automatiquement déployé avec le changement de code d'application correspondant. Cela permet de combler l'écart avec les développeurs qui oublient de propager les changements dans leur base de données locale jusqu'à une base 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 lisses 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 dessus. Il y a un point général ici à souligner, je pense, que vous ne pouvez automatiser que la version et la mise à niveau de la base de données 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 il va soit créer une nouvelle base de données, soit mettre à 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 créer des 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.

1. Script votre base de données
2. Apportez des modifications aux scripts ou directement sur votre serveur db
3. Synchronisez à l'aide de Données> Comparaison de schéma

Fait une solution de versioning DB parfaite, et rend la synchronisation de DB un jeu d'enfant.

C'est une bonne approche pour enregistrer des 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 pouvez également vouloir 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 une 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 pour gérer les métadonnées de 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 contrôlables par la version, etc.

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

J'utilise actuellement DbUp , et cela fonctionne bien.

Vous n'avez pas mentionné de détails sur votre environnement cible ou vos contraintes, donc cela peut 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 à votre portée.

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

Étant donné que les migrations font partie d' ActiveRecord , elles sont généralement utilisées dans les applications Rails à pile complète; cependant, vous pouvez utiliser ActiveRecord indépendamment de Rails avec un effort minimal. Voir ici pour un traitement plus détaillé de l'utilisation des migrations AR en dehors de Rails.

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

C'est simple.

1. Lorsque le projet de base est prêt, vous devez créer un script de base de données complet. Ce script est validé pour SVN. C'est la première version.

2. Après cela, tous les développeurs créent des scripts de changement (ALTER ..., de nouvelles tables, sprocs, etc.).

3. Lorsque vous avez besoin de la version actuelle, vous devez exécuter tous les nouveaux scripts de modification.

4. Lorsque l'application est mise en production, vous revenez à 1 (mais ce sera bien sûr une version successive).

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

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

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

Configuration: créez une table dans chaque base de données que vous souhaitez vérifier de manière incrémentielle pour conserver 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 analyser à nouveau 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 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

Remarque: Si vous utilisez un classement non standard dans l'une de vos bases de données, vous devrez le remplacer /* COLLATE */par le classement de votre base de données. c'est à direCOLLATE 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 en utilisant le format de couple neutre en base de données (XML). Nous contrôlons également la version des données de référence pour 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 locaux pour générer la mise à niveau du schéma et les scripts de mise à niveau des données de référence qui sont nécessaires pour passer de la version X de la base de données à la version X + 1.

Si vous avez une petite base de données et que vous souhaitez mettre à jour la totalité de la chose, ce script batch peut vous aider. Il détache, compresse et vérifie un fichier MDF de base de données MSSQL dans Subversion.

Si vous voulez surtout mettre à jour votre schéma et avoir juste une petite quantité de données de référence, vous pouvez éventuellement utiliser Migrations SubSonic pour gérer cela. L'avantage est que vous pouvez facilement migrer vers le haut ou vers le bas vers n'importe quelle version spécifique.

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 est de stocker les modifications de schéma afin de créer un script de changement 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 qui peut lire ce script et savoir quelles mises à jour doivent être appliquées. Il a également suffisamment d'intelligence pour actualiser les vues et les procédures stockées selon les besoins.

Nous avions besoin de versionner notre base de données SQL après avoir migré vers une plateforme 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:

                Racine
                    Nom du serveur
                       Nom de la base de données
                          Objets de schéma
                             Déclencheurs de base de données *
                                .ddltrigger.sql
                             Les fonctions
                                ..function.sql
                             Sécurité
                                Les rôles
                                   Rôles d'application
                                      .approle.sql
                                   Rôles de base de données
                                      .role.sql
                                Schémas *
                                   .schema.sql
                                Utilisateurs
                                   .user.sql
                             Espace de rangement
                                Catalogues de texte intégral *
                                   .fulltext.sql
                             Procédures stockées
                                ..proc.sql
                             Synonymes *
                                .synonym.sql
                             les tables
                                ..table.sql
                                Contraintes
                                   ... chkconst.sql
                                   ... defconst.sql
                                Index
                                   ... index.sql
                                Clés
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Déclencheurs
                                   ... trigger.sql
                             Les types
                                Types de données définis par l'utilisateur
                                   ..uddt.sql
                                Collections de schémas XML *
                                   ..xmlschema.sql
                             Vues
                                ..view.sql
                                Index
                                   ... index.sql
                                Déclencheurs
                                   ... 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é que l'exécution du processus une fois par nuit était suffisante car nous n'apportons pas autant de modifications à SQL. Il nous permet de suivre les modifications apportées à tous les objets qui nous intéressent et nous permet 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 va scanner vos bases de données SQL MSFT aussi souvent que vous le souhaitez et vider automatiquement vos objets (tables, vues, procs, fonctions, paramètres sql) dans SVN. Fonctionne comme un charme. Je l'utilise avec Unfuddle (ce qui me permet d'obtenir des alertes sur les enregistrements)

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

Selon votre plate-forme de développement, il peut y avoir des plugins opensource disponibles. Rouler votre propre code pour le faire est généralement assez trivial.

Remarque: vous souhaiterez peut-être sauvegarder le vidage de la base de données au lieu de le placer dans le contrôle de version. Les fichiers peuvent devenir extrêmement 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 pour le 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 projet avec des outils intégrés de comparaison, de comparaison de données, de refactorisation de base de données, de cadre de test de base de données et même de génération de données.

Mais, ce modèle ne convient pas très bien aux bases de données très volumineuses ou tierces (qui chiffrent les objets). Donc, ce que nous avons fait, c'est de ne stocker que nos objets personnalisés. Le serveur de fondation Visual Studio / Team fonctionne très bien pour cela.

Arc principal de la base de données TFS. Blog

Site MS TFS

Je suis d'accord avec la réponse d'ESV et pour cette raison exacte, 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é avec un code source à long terme. Il permet des mises à jour faciles pour les développeurs ainsi que pour l'UAT et la production. L'outil fonctionne sur Sql Server et MySql.

Quelques fonctionnalités du projet:

• Autorise les modifications de schéma
• Permet la valeur de la population d'arbres
• Permet des insertions de données de test séparées, par exemple. UAT
• Permet une 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 seule commande simple (serveur SQL uniquement ... toujours en fonctionnement sur mysql)

Le code est hébergé sur le code Google. 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 un script de base de données complet hors et dans VSS. Je l'ai transformé en un script VB et l'ai publié 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 de commandes 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 a des scripts pour chaque étape de la version (c'est-à-dire 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'y a aucun script qui a la version «finale» directe, même le déploiement sur une base de données propre le fait 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 au sujet de la nouvelle et prochaine édition VS DB. La présentation s'est concentrée spécifiquement sur ce sujet et j'ai été soufflé hors de l'eau. Vous devriez certainement le vérifier, les nouvelles fonctionnalités sont axées sur la conservation de la définition de schéma dans les scripts T-SQL (CREATEs), un moteur delta d'exécution pour comparer le schéma de déploiement avec le schéma défini et faire les delta ALTERs et l'intégration avec l'intégration du code source, jusqu'à et incluant l'intégration continue MSBUILD pour les suppressions de build automatisées. La liste contient un nouveau type de fichier, les fichiers .dbschema, qui peut être transféré sur le site de déploiement et un outil en ligne de commande peut effectuer les «deltas» réels et exécuter le déploiement. J'ai une entrée 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 très vieille question, mais beaucoup essaient de résoudre ce problème même 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 la gestion des versions, cela simplifie tout.

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

1. Vous devez gérer les modifications de la base de données de développement effectuées par plusieurs développeurs pendant le développement.

2. Vous devez gérer les mises à niveau de la base de données dans les sites des clients.

Pour gérer # 1, vous aurez besoin d'un puissant outil de diff / fusion de base de données. Le meilleur outil devrait être en mesure d'effectuer autant que possible la fusion automatique tout en vous permettant de résoudre manuellement les conflits non gérés.

L'outil parfait devrait 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 un support de fusion manuel pour les bases de données SQLite et j'ajoute actuellement un support pour l'algorithme de fusion à 3 voies pour SQLite. Découvrez-le sur http://www.sqlitecompare.com

Afin de gérer # 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 d'un schéma SQL existant vers le schéma SQL plus récent et peut créer un chemin de mise à niveau pour chaque installation de base de données existante.

Consultez 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 Levi

Consultez DBGhost http://www.innovartis.co.uk/ . Je l'utilise de manière automatisée depuis 2 ans maintenant et ça marche très bien. Il permet à nos builds DB de se produire un peu comme un build Java ou C, sauf pour la base de données. Tu sais ce que je veux dire.

Je suggère 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 xSQL Schema Compare et xSQL Data Compare .

Maintenant, si votre objectif est de n'avoir que 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, il suffit de comparer 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 n'importe quelle version de votre choix. Gardez à l'esprit que pour la fonctionnalité de retour, vous devez générer des scripts de changement qui, une fois exécutés, rendront la version 3 identique à la version 2 et pour la fonctionnalité de mise à jour, vous devez générer des scripts de changement qui font le contraire.

Enfin, avec certaines 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

Avertissement: je suis affilié à xSQL.