base de données SQL Server Versioning

voix
288

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

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

Créé 01/08/2008 à 19:33
source utilisateur
Dans d'autres langues...                            


29 réponses

voix
169

Martin Fowler a écrit mon article préféré sur le sujet, http://martinfowler.com/articles/evodb.html . Je choisis de ne pas mettre en schéma décharges sous contrôle de version comme alumb et d' autres suggèrent parce que je veux un moyen facile de mettre à jour ma base de données de production.

Pour une application web où je vais avoir une seule instance de base de données de production, j'utilise deux techniques:

Base de données des scripts de mise à niveau

Une base de données de séquence de mise à niveau des scripts qui contiennent le DDL nécessaire de déplacer le schéma de la version N à 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 fois un script de mise à niveau court 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 à jour de bases de données sont gérées qu'une seule fois. Encore une fois, ce sont pas des décharges de base de données. Au contraire, chaque script représente les changements nécessaires pour passer d'une version à l'autre. Ils sont le script que vous appliquez à votre base de données de production à « mettre à jour » il.

Développeur Bac à sable synchronisation

  1. Un script de sauvegarde, désinfectez et rétrécir une base de données de production. Exécutez cette après chaque mise à niveau vers la production DB.
  2. Un script pour restaurer (et tweak, le cas échéant) 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 production DB.

Une mise en garde: Mes tests automatisés exécuté sur une base de données schéma correct, mais vide, donc ce conseil conviendra pas parfaitement à vos besoins.

Créé 02/08/2008 à 18:33
source utilisateur

voix
42

Red Gate SQL Comparer le produit vous permet non seulement de faire des comparaisons au niveau de l'objet, et de générer des scripts de modification 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 un [nom_objet] .sql création scénario par objet dans ces répertoires. La hiérarchie de type d'objet est comme ceci:

\ Fonctions
\ Security
\ Security \ Rôles
\ Security \ Schemas
\ Security Users \
\ Les procédures stockées
\ Tableaux

Si vous videz vos scripts dans le même répertoire racine après que vous apportez des modifications, vous pouvez l'utiliser pour mettre à jour votre repo SVN, et conserver un historique en cours d'exécution de chaque objet individuellement.

Créé 26/08/2008 à 08:23
source utilisateur

voix
38

Ceci est l'un des « problèmes difficiles » entourant le développement. Pour autant que je sais qu'il n'y a pas de solution parfaite.

Si vous avez seulement besoin de stocker la structure de base de données et non les données que vous pouvez exporter la base de données des requêtes SQL. (Dans Enterprise Manager: Faites un clic droit sur la base de données -> Générer un script SQL que je vous recommande de la « créer un fichier par objet » sur l'onglet Options.) Vous pouvez ensuite valider ces fichiers texte à svn et utiliser des diff et des fonctions forestières svn.

J'ai ce lié avec un script batch qui prend un paramètre de couple et met en place la base de données. J'ai aussi ajouté quelques requêtes supplémentaires qui entrent dans les données par défaut comme les types d'utilisateurs et l'utilisateur admin. (Si vous voulez plus d'informations sur ce sujet, poster quelque chose et je peux mettre quelque part le script accessible)

Si vous avez besoin de garder toutes les données aussi bien, je recommande de garder une sauvegarde de la base de données et en utilisant Redgate ( http://www.red-gate.com/ produits) pour faire les comparaisons. Ils ne viennent pas pas cher, mais ils valent chaque centime.

Créé 01/08/2008 à 20:28
source utilisateur

voix
37

Tout d'abord, vous devez choisir le système de contrôle de version qui est bon pour vous:

  • Version centralisée Système de contrôle - un système standard où les utilisateurs vérifier / vérifier avant / après qu'ils travaillent sur les fichiers et les fichiers sont conservés dans un seul serveur central

  • Système de contrôle distribué version - un système où le dépôt est cloné, et chaque clone est en fait la sauvegarde complète du référentiel, donc si tout serveur tombe en panne, alors tout dépôt cloné peuvent être utilisés 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 tous les systèmes 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-contrôle-base /

Après la mise en place d' un dépôt, et dans le cas d'un système de contrôle de version centrale un dossier de travail, vous pouvez lire cet article . Il montre comment l'environnement dans la configuration d' un contrôle de code source de développement à l' aide:

  • SQL Server Management Studio via le fournisseur MSSCCI,

  • Visual Studio et Outils de données SQL Server

  • Un outil 3ème partie ApexSQL contrôle Source
Créé 24/06/2015 à 10:36
source utilisateur

voix
22

Ici , à Red Gate nous offrons un outil, SQL Source Control , qui utilise SQL Comparer la technologie pour relier la base de données avec un référentiel TFS ou SVN. Cet outil intègre SSMS et vous permet de travailler comme vous le feriez normalement, sauf qu'il vous permet de valider maintenant les objets.

, Nous offrons pour une approche basée sur les migrations (plus adapté pour les déploiements automatisés) ReadyRoll , qui crée et gère un ensemble de scripts supplémentaires comme un projet Visual Studio.

Dans SQL Source de contrôle, il est possible de spécifier des tables de données statiques. Ceux-ci sont stockés dans le contrôle des sources comme INSERT IGNORE déclarations.

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

Créé 01/07/2010 à 10:10
source utilisateur

voix
20

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

Créé 16/09/2008 à 19:16
source utilisateur

voix
17

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

SqlCompare dispose également d'une API décemment documentée: si vous pouvez, par exemple, écrire une application console qui synchronise vos scripts contrôle source dossier avec une base de données de tests d'intégration de CI sur checkin, de sorte que quand quelqu'un vérifie un changement au schéma de leur dossier scripts il est automatiquement déployé en même temps que le changement de code d'application correspondant. Cela aide à combler l'écart avec les développeurs qui sont oublieux propager au sujet des changements dans leur communauté locale db à un développement partagé DB (environ la moitié d'entre nous, je pense :)).

Une mise en garde est que, avec une solution scriptée ou autrement, les outils de Redgate sont suffisamment lisses qu'il est facile d'oublier les réalités SQL sous-tendent l'abstraction. Si vous renommez toutes les colonnes d'une table, SqlCompare n'a aucun moyen de cartographier les anciennes colonnes aux nouvelles colonnes et chutera toutes les données dans le tableau. Il génère des avertissements mais j'ai vu les gens cliquent passé. Il y a un point général ici la peine de faire, je pense, que vous ne pouvez automatiser DB versioning et mettre à jour à ce jour - les abstractions sont très leaky.

Créé 15/10/2008 à 10:44
source utilisateur

voix
14

Avec VS 2010, utilisez le projet de base de données.

  1. Script votre base de données
  2. Apporter des modifications aux scripts ou directement sur votre serveur db
  3. Synchronisation à l'aide de données> Comparaison de schémas

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

Créé 25/02/2011 à 21:18
source utilisateur

voix
14

Nous utilisons DBGhost pour gérer notre base de données SQL. Ensuite , vous mettez vos scripts pour construire une nouvelle base de données dans votre contrôle de version, et il va soit construire une nouvelle base de données, ou de mettre à jour une base de données existante au schéma de contrôle de version. De cette façon , vous n'avez pas à vous soucier de créer des scripts de modification (même si vous pouvez toujours le faire, par exemple si vous souhaitez modifier le type de données d'une colonne et doivent convertir des données).

Créé 07/08/2008 à 22:12
source utilisateur

voix
12

Il est une bonne approche pour sauvegarder les scripts de base de données dans le contrôle de version avec des scripts de modification afin que vous pouvez mettre à jour toute une base de données que vous avez. Aussi, vous pouvez enregistrer des schémas pour différentes versions afin que vous puissiez créer une base de données complète sans avoir à appliquer tous les scripts de modification. Manipulation des scripts doit être automatisé afin que vous ne devez pas faire du travail manuel.

Je pense qu'il est important d'avoir une base de données distincte pour chaque développeur et 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 les phases de développement indépendamment des autres développeurs.

L'outil automatisant doit disposer de moyens pour les métadonnées de base de données de manipulation, ce qui indique que les bases de données sont dans quel état de développement et qui contiennent des données contrôlables tables de version et ainsi de suite.

Créé 24/09/2008 à 07:11
source utilisateur

voix
11

Vous pouvez aussi regarder une solution de migrations. Celles-ci vous permettent de spécifier votre schéma de base de données dans le code C # et rouler votre version de base de données de haut en bas à l'aide MSBuild.

Je suis actuellement à l' aide DbUp , et il fonctionne bien.

Créé 06/08/2008 à 23:51
source utilisateur

voix
10

Vous n'avez pas parlé des détails au sujet de votre environnement cible ou contraintes, donc cela ne peut être tout à fait applicable ... mais si vous êtes à la recherche d'un moyen de suivre efficacement un schéma de base de données en constante évolution et ne sont pas défavorables à l'idée d'utiliser Ruby, les migrations de ActiveRecord sont jusqu'à votre allée.

Définir des transformations programatically migration de base de données en utilisant un DSL Ruby; chaque transformation peut être appliquée ou (généralement) annulée, ce qui vous permet de passer à une autre version de votre schéma de DB à un moment donné dans le temps. Le fichier définissant ces transformations peut être vérifié dans le contrôle de version comme tout autre morceau de code source.

Parce que les migrations font partie de ActiveRecord , ils trouvent généralement une utilisation en pleine pile Rails applications; Cependant, vous pouvez utiliser ActiveRecord indépendant de Rails avec un minimum d' effort. Voir ici pour un traitement plus détaillé de l' utilisation des migrations AR en dehors des rails.

Créé 02/08/2008 à 18:54
source utilisateur

voix
9

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

Créé 07/07/2009 à 13:58
source utilisateur

voix
8

C'est simple.

  1. Lorsque le projet de base est prêt, vous devez créer le script complet de base de données. Ce script est engagé à SVN. Il est première version.

  2. Après que tous les développeurs crée des scripts de modification (... ALTER, de nouvelles tables, sprocs, etc.).

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

  4. Lorsque l'application est libéré à la production puis vous revenez à 1 (mais il sera la version successive bien sûr).

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

Et rappelez-vous. Tout fonctionne très bien quand il y a la discipline. Chaque fois que le changement de base de données est alors commited fonctions correspondantes dans le code sont commited aussi.

Créé 16/05/2009 à 12:31
source utilisateur

voix
7

Pour la décharge à un système de contrôle de code source qui peu plus vite, vous pouvez voir quels objets ont changé depuis la dernière fois en utilisant les informations de version dans sysobjects.

Configuration: Créer une table dans chaque base de données que vous voulez vérifier progressivement pour tenir les informations de version de la dernière fois que vous vérifié (vide dans la première manche). Désactivez cette table si vous voulez 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 cette sql et générer des scripts SQL pour seulement ceux qui vous intéressent, et les mettre 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 IGNORE  #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 IGNORE  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 une collation non standard dans l' une de vos bases de données, vous devrez remplacer /* COLLATE */votre collation de base de données. c'est à direCOLLATE Latin1_General_CI_AI

Créé 24/09/2008 à 13:53
source utilisateur

voix
7

Parce que notre application doit travailler sur plusieurs SGBDR, nous stockons notre définition de schéma dans le contrôle de version en utilisant la base de données neutre couple Format (XML). Nous contrôlons également 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 cultivés sur place pour générer la mise à niveau du schéma et les données de référence de mise à niveau des scripts qui sont nécessaires pour passer de la version X de la base de données à la version X + 1.

Créé 24/09/2008 à 06:49
source utilisateur

voix
7

Si vous avez une petite base de données et que vous voulez à la version la chose entière, ce script batch pourrait aider. Il se détache, compresse et vérifie un fichier MDF de base de données MSSQL pour Subversion.

Si vous voulez la plupart du temps à la version de votre schéma et juste une petite quantité de données de référence, vous pouvez éventuellement utiliser SubSonic Migration pour gérer cela. L'avantage il est que vous pouvez facilement migrer vers le haut ou vers le bas pour une version spécifique.

Créé 07/08/2008 à 22:21
source utilisateur

voix
6

J'ai écrit cette application il y a un certain temps, http://sqlschemasourcectrl.codeplex.com/ qui va scanner votre MSFT de SQL db aussi souvent que vous le souhaitez et vider automatiquement vos objets (tables, vues, procs, les fonctions, les paramètres de sql) dans SVN. Fonctionne comme un charme. Je l' utilise avec Unfuddle (qui me permet d'obtenir des alertes sur checkins)

Créé 23/09/2010 à 03:35
source utilisateur

voix
6

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

                Racine
                    Nom du serveur
                       Nom de la base de données
                          Objets de schéma
                             Déclenche 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èmes
                                   .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
                                indices
                                   ... 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
                                indices
                                   ... index.sql
                                déclencheurs
                                   ... trigger.sql

L'application serait alors comparer la nouvelle version écrite à la version stockée dans SVN et s'il y avait des différences qu'il mettrait à jour SVN. Nous avons déterminé que le processus en cours d'exécution une fois par nuit était suffisant puisque nous ne faisons pas que de nombreux changements à SQL. Il nous permet de suivre les changements à tous les objets qui nous intéressent plus il nous permet de reconstruire notre schéma complet en cas d'un problème grave.

Créé 09/10/2008 à 15:54
source utilisateur

voix
6

Nous ne stockons pas le schéma de base de données, nous enregistrons les modifications apportées à la base de données. Ce que nous faisons est de stocker les modifications du schéma afin que nous construisons un script de changement pour toute version de la base de données et l'appliquer aux bases de données de nos clients. J'ai écrit une application utilitaire de base de données qui est distribué avec notre application principale qui peut lire ce script et de savoir qui doivent être appliquées les mises à jour. Il a également assez débrouillard pour actualiser les vues et les procédures stockées au besoin.

Créé 07/08/2008 à 00:00
source utilisateur

voix
5

Je suis d'accord avec la réponse ESV et pour cette raison exacte, j'ai commencé un peu de projet en arrière pour aider à maintenir les mises à jour de base de données dans un fichier très simple qui pourra être maintenu un côté long sur le code source. Il permet des mises à jour faciles aux développeurs ainsi que UAT et de la production. L'outil fonctionne sur mais Sql Server et MySql.

Quelques caractéristiques du projet:

  • Permet des modifications du schéma
  • Permet la population d'arbres de valeur
  • Permet inserts de données de test séparées pour par exemple. UAT
  • Permet option d'invalidation (non automatisée)
  • Maintient un soutien pour le serveur SQL 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 ... travaille toujours sur MySQL)

Le code est hébergé sur google code. S'il vous plaît vérifier le code de Google pour certains plus d'informations

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

Créé 24/02/2011 à 19:28
source utilisateur

voix
5

Nous venons tout juste commencé à utiliser Team Foundation Server. Si votre base de données est de taille moyenne, puis visual studio a des intégrations belles du projet avec construit dans COMPARE de comparaison de données, outils de refactorisation de base de données, le cadre de tests de base de données, et même des outils de génération de données.

Mais, ce modèle ne correspond pas à de très grandes bases de données ou de tiers (que les objets de Crypter) très bien. Donc, ce que nous avons fait est de stocker seulement nos objets personnalisés. Visual Studio / serveur Team Foundation fonctionne très bien pour cela.

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

Site MS TFS

Créé 22/08/2008 à 18:13
source utilisateur

voix
5

La solution typique est de vider la base de données que nécessaire et la sauvegarde de ces fichiers.

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

Remarque: Vous pouvez sauvegarder le vidage de la base de données au lieu de le mettre dans le contrôle de version. Les fichiers peuvent obtenir rapidement énorme dans le contrôle de version, et provoquer l'ensemble de votre système de contrôle de code source pour devenir lent (je rappelle une histoire d'horreur CVS pour le moment).

Créé 03/08/2008 à 02:49
source utilisateur

voix
4

J'utilise également une version dans la base de données stockée via la base de données des propriétés famille élargie des procédures. Mon application a des scripts pour chaque étape de la version (ie. Déplacent 1,1 à 1,2). Lorsqu'il est déployé, il se penche sur la version actuelle et exécute ensuite les scripts un par un jusqu'à ce qu'il atteigne la dernière version de l'application. Il n'y a pas de script qui a la version « finale » droite, même déployer sur une surface propre DB fait Deploy par une série d'étapes de mise à niveau.

Maintenant , ce que je tiens à ajouter que je l' ai vu il y a deux jours une présentation sur le campus MS au sujet de la nouvelle édition à venir VS DB. La présentation a été axée spécifiquement sur ce sujet et je soufflé hors de l'eau. Vous devriez vraiment vérifier, les nouvelles installations sont axées sur la définition du schéma maintien dans les scripts T-SQL (CRÉE), un moteur delta d'exécution pour comparer le schéma de déploiement avec le schéma défini et faire le delta ALTERs et l' intégration avec l' intégration de code source, jusqu'à et notamment MSBUILD intégration continue pour les chutes de construction automatisés. La baisse contiendra un nouveau type de fichier, les fichiers .dbschema, qui peuvent être prises sur le site de déploiement et un outil de ligne de commande peut faire le « deltas » réelle 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 vérifier: http://rusanu.com/2009/05/15/version-control-and-your-database/

Créé 15/05/2009 à 20:26
source utilisateur

voix
4

Il y a quelque temps j'ai trouvé un module bas VB qui utilise DMO et objets VSS pour obtenir un db ensemble scénarisé hors et dans VSS. Je me suis tourné dans un script VB et posté ici . Vous pouvez facilement prendre les appels VSS et utiliser la substance DMO pour générer tous les scripts, puis appeler SVN à partir du même fichier batch qui appelle le VBScript pour les enregistrer?

Dave J

Créé 16/09/2008 à 18:55
source utilisateur

voix
3

Son cependant beaucoup sont une question très ancienne, en essayant de résoudre ce même maintenant. Tout ce qu'ils ont à faire est de la recherche sur les projets de base de données Visual Studio. Sans cela, tout développement de base de données est très faible. De l'organisation du code au déploiement de versioning, il simplifie tout.

Créé 23/06/2015 à 11:26
source utilisateur

voix
2

Consultez DBGhost http://www.innovartis.co.uk/ . Je l' ai utilisé de façon automatisée depuis 2 ans maintenant et il fonctionne très bien. Il permet à notre DB construit de se produire un peu comme une version Java ou C se produit, à l' exception de la base de données. Tu sais ce que je veux dire.

Créé 02/11/2009 à 23:17
source utilisateur

voix
2

Dans mon expérience, la solution est double:

  1. Vous devez gérer les changements à la base de données de développement qui sont faites par plusieurs développeurs au cours du développement.

  2. Vous devez gérer les mises à jour de bases de données sur les sites clients.

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

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

J'ai écrit un outil commercial qui offre un soutien de fusion manuelle des bases de données SQLite et je suis actuellement l' ajout du support pour 3 voies algorithme de fusion pour SQLite. Check it out à 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 à partir d'un schéma SQL existant vers le nouveau schéma SQL et peut construire un chemin de mise à niveau pour chaque installation de DB existante.

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

Bonne chance

Liron Levi

Créé 06/08/2009 à 11:28
source utilisateur

voix
1

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 sont xSQL Comparaison de schémas et xSQL données Comparer .

Maintenant, si votre objectif est d'avoir que sur le schéma de la base de données sous le contrôle de version, vous pouvez simplement utiliser xSQL schéma pour générer Comparer xSQL instantanés du schéma et ajouter ces fichiers dans votre contrôle de version. Que, de revenir ou de mise à jour à une version spécifique suffit de comparer la version actuelle de la base de données avec l'instantané pour la version de destination.

Hélas, si vous voulez avoir les données sous contrôle de version ainsi, vous pouvez utiliser xSQL données Comparer pour générer des scripts de modification pour la base et ajoutez les fichiers .sql dans votre contrôle de version. Vous pouvez ensuite exécuter ces scripts pour revenir / mise à jour à une version que vous voulez. Gardez à l'esprit que pour la fonctionnalité « revert » vous devez générer des scripts de modification que lors de l'exécution fera la version 3 de la même que la version 2 et la fonctionnalité « mise à jour », vous devez générer des scripts de modification qui font le contraire.

Enfin, avec des compétences en programmation par lots de base que vous pouvez automatiser le processus en utilisant les versions de ligne de commande de xSQL Comparaison de schémas et données xSQL Comparer

Disclaimer: Je suis affilié à xSQL.

Créé 10/01/2017 à 16:16
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more