Versioning de la base de données SQL Server

Je veux que mes bases de données soient sous contrôle de version. Est-ce que quelqu'un a des conseils ou des articles recommandés pour me lancer?

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

0
ajouté édité
Vues: 10
ajouté l'auteur Marek Grzenkowicz, source
ajouté l'auteur stukelly, source
@ ashy_32bit Logique de stackoverflow / stackexchange typique. C'est ce que je n'aime pas sur ce site web; Beaucoup de bonnes choses se ferment pour des raisons stupides. Je ne publie presque jamais de questions à cause de cela. J'ai des permissions de quasi-modérateur sur le stackexchange de sécurité et je vote pour garder ouvert / rouvrir la moitié des threads qui obtiennent des votes proches.
ajouté l'auteur Luc, source
154 upvotes et 146 favs et fermé? comment cela est-il possible?
ajouté l'auteur ashy_32bit, source
[Versioning Databases - Branching and Merging] nouveau lien: odetocode.com/blogs/scott/archive/2008/02/03/…
ajouté l'auteur Fil, source
Jetez également un coup d'oeil à ce livre blanc; Le Guide définitif du contrôle de version de la base de données www3.dbmaestro.com/&hellip
ajouté l'auteur DBAstep, source

28 Réponses

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 soit créez une nouvelle base de données, soit mettez à niveau n'importe quelle 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 changement (bien que vous puissiez toujours le faire, si par exemple vous voulez changer le type de données d'une colonne et que vous devez convertir des données).

0
ajouté
J'ai utilisé DbGhost pendant 10 ans et ça ne m'a jamais laissé tomber. Le soutien qu'ils fournissent est sans pareil
ajouté l'auteur penderi, source

Nous ne stockons pas le schéma de base de données, nous stockons les modifications dans la base de données. Ce que nous faisons, c'est stocker les changements de schéma afin que nous puissions construire un script de changement pour n'importe quelle version de la base de données et l'appliquer aux bases de données de nos clients. J'ai écrit une application 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 assez d'intelligence pour actualiser les vues et les procédures stockées au besoin.

0
ajouté

Vous pouvez également regarder une solution de migration. Ceux-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 en utilisant MSBuild.

J'utilise actuellement DbUp , et cela fonctionne bien.

0
ajouté

Si vous avez une petite base de données et que vous voulez la version complète, ce script batch peut aider. Il détache, compresse et vérifie un fichier MDF de base de données MSSQL dans Subversion.

Si vous voulez principalement mettre à jour votre schéma et juste avoir 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 le bas vers une version spécifique.

0
ajouté

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émas sous le 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:

Scripts de mise à niveau

A sequence Scripts de mise à niveau that contain the DDL necessary to move the schema from version N to N+1. (These go in your version control system.) A _version_history_ table, something like

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.

This ensures that it's easy to see what version of the database schema exists and that Scripts de mise à niveau are run only once. Again, these are not database dumps. Rather, each script represents the changes necessary to move from one version to the next. They're the script that you apply to your production database to "upgrade" it.

Développeur Sandbox Synchronisation

  1. Un script pour sauvegarder, désinfecter 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.
  2. Un script pour restaurer (et ajuster, 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 correcte mais vide, donc ce conseil ne répondra pas parfaitement à vos besoins.

0
ajouté
Ce qui est vraiment frustrant, c'est qu'un projet de base de données VS peut générer les scripts nécessaires pour ces mises à jour de schéma, mais il les appliquera directement. Il ne gérera pas l'histoire de la version. Vous devez le faire manuellement, et si vous oubliez même d'ajouter manuellement le script de mise à jour, vous êtes foutu car votre base de données sera déjà mise à jour et le projet de base de données ne générera plus le même script de mise à jour. J'aimerais qu'il y ait un type de projet qui gère la gestion de base de données versionnée .
ajouté l'auteur Jez, source
La réponse de @ nikc.org, plus les hooks post-commit pour l'automatisation.
ajouté l'auteur Silviu-Marian, source
J'ai l'habitude de maintenir un script complet de création et de suppression, ainsi que des scripts delta pour la mise à jour des instances db existantes. Les deux vont dans le contrôle de version. Les scripts delta sont nommés en fonction des numéros de révision. De cette façon, il est facile d'automatiser le patching db avec un script de mise à jour.
ajouté l'auteur nikc.org, source
Dites-vous que vous mettez des scripts de mise à niveau dans le contrôle de la source, écrou ne pas mettre ceux de restauration là-bas?
ajouté l'auteur A-K, source
La version contrôlant les scripts de schéma complets est très utile à titre de référence. Par exemple, il est impossible de voir exactement ce qui a été changé dans une procédure stockée en regardant l'instruction ALTER PROCEDURE.
ajouté l'auteur Constantin, source
Le vidage (et la gestion des versions) du schéma de base de données complet après l'exécution de nouveaux scripts de mise à niveau est un bon moyen de rendre les informations disponibles aux autres outils de votre processus de génération / déploiement. De plus, avoir le schéma complet dans un script signifie être capable de "faire tourner" une nouvelle base de données sans passer par toutes les étapes de la migration. Il permet également de comparer la version actuelle aux versions précédentes accumulées.
ajouté l'auteur mlibby, source
Je le fais aussi, mais je garde un fichier de sauvegarde ordinaire dans le contrôle de source à la place d'un script de génération complète. Plus rapide et moins problématique, selon mon expérience. Cela rend la comparaison entre les versions arbitraires un peu plus difficile, mais là encore, cela n'arrive pas souvent, et les scripts de mise à jour sont parfaitement consultables, ce qui devrait suffire, car tous les changements les traversent. En outre, pour les numéros de version dans la base de données elle-même, j'ai mis une propriété étendue sur l'objet de base de données. De cette façon,
ajouté l'auteur Atario, source

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é par SVN. C'est la première version.

  2. Après que 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. Quand l'application est lancée en production, alors vous revenez à 1 (mais alors ce sera une version successive bien sûr).

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

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

0
ajouté
Après quelques années, je dis: Utilisez FluentMigrator (ou un outil similaire pour votre plate-forme).
ajouté l'auteur dariol, source

J'utilise également une version dans la base de données stockée via la famille de procédures étendues de propriétés de 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 regarde la version actuelle et exécute 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 base de données propre le déploiement via une série d'étapes de mise à niveau.

Now what I like to add is that I've seen two days ago a presentation on the MS campus about the new and upcoming VS DB edition. The presentation was focused specifically on this topic and I was blown out of the water. You should definitely check it out, the new facilities are focused on keeping schema definition in T-SQL scripts (CREATEs), a runtime delta engine to compare deployment schema with defined schema and doing the delta ALTERs and integration with source code integration, up to and including MSBUILD continuous integration for automated build drops. The drop will contain a new file type, the .dbschema files, that can be taken to the deployment site and a command line tool can do the actual 'deltas' and run the deployment. I have a blog entry on this topic with links to the VSDE downloads, you should check them out: http://rusanu.com/2009/05/15/version-control-and-your-database/

0
ajouté

Nous avions besoin de mettre à jour notre base de données SQL après notre migration 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:

                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 cela mettrait à jour SVN. Nous avons déterminé que l'exécution du processus une fois par nuit était suffisante car nous n'effectuons pas beaucoup de changements dans SQL. Il nous permet de suivre les changements de tous les objets qui nous intéressent et nous permet de reconstruire notre schéma complet en cas de problème sérieux.

0
ajouté
Oooh, ce serait génial de rendre public.
ajouté l'auteur Chris Charabaruk, source

J'ai écrit cette application il y a un certain temps, http://sqlschemasourcectrl.codeplex.com/ qui va scanner votre SQL MSFT DB est 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'avoir des alertes sur checkins)

0
ajouté

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

Pour une approche basée sur les migrations (plus adaptée aux déploiements automatisés), nous proposons 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 source en tant qu'instruction 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.

0
ajouté
Cette réponse est un doublon de la réponse de Dane posté deux ans plus tôt.
ajouté l'auteur Knickerless-Noggins, source
Produit intéressant (peu d'un écart sur le marché) mais les deltas stockés comme "CREER ..." me font peur. Comment branchez-vous / fusionnez-vous?
ajouté l'auteur annakata, source
Nous stockons les définitions d'objet comme CREATE, mais si vous obtenez les dernières informations ou, par exemple, utilisez SQL Compare Pro pour générer des scripts de synchronisation, ceux-ci sont modifiés en les commandes appropriées, telles que ALTER. Pour fusionner ou fusionner, vous devez simplement utiliser votre système de contrôle de source de la même manière que vous le faites actuellement.
ajouté l'auteur David Atkinson, source
C'est une réponse différente. SQL Compare ne contrôle pas les bases de données, tandis que SQL Source Control a été conçu spécifiquement pour cela.
ajouté l'auteur David Atkinson, source

Avec VS 2010, utilisez le projet Database.

  1. Script out your database
  2. Make changes to scripts or directly on your db server
  3. Sync up using Data > Schema Compare

Fait une solution parfaite de versionnement de DB, et fait la synchronisation DB une brise.

0
ajouté
Oui, mais malheureusement, vous devez vous rappeler de "générer un script" à chaque fois. Si vous mettez directement à jour la base de données, vous perdez la possibilité de générer le script de mise à jour pour ce delta. Si seuls les projets de base de données disposent de fonctionnalités intégrées pour la gestion des versions.
ajouté l'auteur Jez, source

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. Cela permet à nos constructions de DB de se produire un peu comme une construction Java ou C, sauf pour la base de données. Tu sais ce que je veux dire.

0
ajouté

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

Setup: Create a table in each database you want to check incrementally to hold the version information from the last time you checked it (empty on the first run). Clear this table if you want to re-scan your whole data structure.

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)
)

Normal running mode: You can take the results from this sql, and generate sql scripts for just the ones you're interested in, and put them into a source control of your choice.

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: If you use a non-standard collation in any of your databases, you will need to replace /* COLLATE */ with your database collation. i.e. COLLATE Latin1_General_CI_AI

0
ajouté
Script très utile, merci.
ajouté l'auteur pmcilreavy, source

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 DB évolutif et que vous n'êtes pas contre l'idée d'utiliser Ruby, les migrations d'ActiveRecord sont à votre portée.

Les migrations définissent par programme des transformations de base de données en utilisant un ruby DSL; Chaque transformation peut être appliquée ou annulée (généralement), 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 vérifié dans le contrôle de version comme n'importe quel autre morceau de code source.

Étant donné que les migrations font partie de 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 minimum d'effort. Voir ici pour un traitement plus détaillé de l'utilisation des AR migrations en dehors de Rails.

0
ajouté

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

If you only need to store the database structure and not the data you can export the database as SQL queries. (in Enterprise Manager: Right click on database -> Generate SQL script. I recommend setting the "create one file per object" on the options tab) You can then commit these text files to svn and make use of svn's diff and logging functions.

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

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

0
ajouté
@Taichman: DataGrove ne semble pas supporter le serveur SQL, et en tant que tel n'a aucun rapport avec la question.
ajouté l'auteur Neolisk, source
Comment déterminez-vous l'ordre d'exécution des scripts de base de données si vous utilisez l'option "un fichier par objet"?
ajouté l'auteur Jamie Kitson, source
en ce qui concerne les données - vous pouvez utiliser rel="nofollow noreferrer"> Offscale DataGrove pour enregistrer les versions de votre base de données entière (données incluses). Vous pouvez l'utiliser plus tard pour générer deux copies virtuelles de votre DB qui peuvent être comparées avec le produit de red-gate. Il vous évite également de devoir générer des données de test - vous pouvez simplement enregistrer les versions de la base de données pour les faire correspondre aux différents cas de test (à nouveau, des copies complètes et virtuelles de la
ajouté l'auteur Taichman, source

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

Selon votre plate-forme de développement, des plugins opensource peuvent être disponibles. Rouler votre propre code pour le faire est généralement assez trivial.

Remarque: Vous pouvez sauvegarder la sauvegarde de la base de données au lieu de la 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 pour le moment).

0
ajouté

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

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

Arche en chef de la base de données TFS. blog

Site MS TFS

0
ajouté

Le produit SQL Compare de Red Gate vous permet non seulement de faire des comparaisons au niveau objet, mais aussi 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 de type objet est comme ceci:

\ Fonctions
\ Sécurité
\ Sécurité \ Rôles
\ Sécurité \ Schémas
\ Security \ Utilisateurs
\ Procédures stockées
\Les tables

Si vous transférez vos scripts dans le même répertoire racine après avoir apporté des modifications, vous pouvez l'utiliser pour mettre à jour votre dépôt SVN et conserver un historique de chaque objet individuellement.

0
ajouté
Nous venons de publier SQL Source Control, qui intègre le comportement SQL Compare décrit dans SSMS et les liens vers SVN et TFS. J'ai ajouté une réponse distincte à cette question qui décrit plus en détail ce qu'il fait. red-gate.com/products/SQL_Source_Control/index.htm
ajouté l'auteur David Atkinson, source

Il y a quelque temps, j'ai trouvé un module VB bas qui utilisait des objets DMO et VSS pour obtenir un script db complet dans VSS. Je l'ai transformé en un script VB et l'ai posté ici . Vous pouvez facilement supprimer les appels VSS et utiliser le composant DMO pour générer tous les scripts, puis appeler SVN à partir du même fichier de commandes qui appelle le script VBScript pour les vérifier?

Dave J

0
ajouté

Vous pourriez vouloir regarder 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 changements de base de données ou de refactoring.

0
ajouté
Nous utilisons Liquibase dans 5 équipes réparties sur une seule branche pour une livraison continue et cela fonctionne très bien. Nous avons installé plus de 10 applications de base de données dans de nombreux environnements différents. Nous l'utilisons pour gérer le schéma, l'indexation, le partitionnement, le code, les données de recherche, les groupes et les permissions de groupe. Nous l'utilisons pour Oracle, Postgresql et MSSQL.
ajouté l'auteur Peter Henell, source
Si je comprends bien sur la base de l'intro, il faut que vous connaissiez un langage xml propriétaire pour déclarer vos objets au lieu de SQL? Pas un fan.
ajouté l'auteur JDPeckham, source

É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 Couple format (XML). Nous contrôlons également les 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):

  
  
  etc.

Nous utilisons ensuite des outils locaux pour générer les scripts de mise à niveau de schéma et de mise à niveau des données de référence requis pour passer de la version X de la base de données à la version X + 1.

0
ajouté

C'est une bonne approche pour enregistrer des scripts de base de données dans le contrôle de version avec des scripts de changement afin que vous puissiez mettre à jour n'importe quelle base de données que vous avez. Vous pouvez é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 manipulation des scripts devrait être automatisée de sorte que vous n'ayez pas à faire de travail manuel.

Je pense qu'il est important d'avoir une base de données séparée 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 devrait avoir des moyens pour gérer les métadonnées de la base de données, qui indique quelles bases de données sont dans quel état de développement et quelles tables contiennent des données contrôlables par version, etc.

0
ajouté

+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 documentée de manière décente: vous pouvez par exemple écrire une application de console qui synchronise votre dossier de scripts contrôlé par la source avec une base de données d'intégration CI lors de l'archivage, de sorte que lorsque quelqu'un vérifie le schéma du dossier scripts il est automatiquement déployé avec le changement de code d'application correspondant. Cela aide à combler le fossé avec les développeurs qui oublient de propager les changements dans leur base de données locale à un DB de développement partagé (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 sur les nouvelles colonnes et supprimera toutes les données de la table. Cela va générer des avertissements, mais j'ai vu des gens cliquer dessus. Je pense qu'il vaut la peine de souligner que vous ne pouvez qu'automatiser les versions de DB et les mettre à niveau jusqu'à présent - les abstractions sont très fuites.

0
ajouté
Il convient de garder à l'esprit que pour les changements de base de données qui ont une ambiguïté (et qui ont donc besoin d'un élément «intention du développeur»), une solution basée sur les migrations est la solution appropriée. Redgate a maintenant ReadyRoll qui satisfait cette approche de versionnement.
ajouté l'auteur David Atkinson, source
Il devrait donc y avoir un système permettant de suivre les colonnes que vous modifiez et de mémoriser les correspondances entre les anciens noms de colonnes et les nouveaux noms de colonnes.
ajouté l'auteur Silvercode, source

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

  1. 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.

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

Afin de gérer # 1, vous aurez besoin d'un outil de comparaison / fusion de bases de données. Le meilleur outil devrait être capable d'effectuer une fusion automatique autant que possible 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 à trois voies qui tient compte des changements qui ont été faits dans la base de données THEIRS et la base de données MINE, par rapport à la base de données BASE.

I wrote a commercial tool that provides manual merge support for SQLite databases and I'm currently adding support for 3-way merge algorithm for SQLite. Check it out at 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 passer d'un schéma SQL existant au schéma SQL plus récent et qui 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

0
ajouté

Je suis d'accord avec la réponse de ESV et pour cette raison exacte j'ai commencé un petit projet il y a un moment pour aider à maintenir les mises à jour de base de données dans un fichier très simple qui pourrait alors être maintenu un long code source. Il permet des mises à jour faciles pour les développeurs ainsi que UAT et Production. L'outil fonctionne sur mais SQL Server et MySQL.

Certaines caractéristiques du projet:

  • Autorise les modifications de schéma
  • Autorise la population d'arbres de valeurs
  • Permet des insertions de données de test séparées pour par ex. UAT
  • Autorise l'option de restauration (non automatisée)
  • Maintient le support 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 seulement ... fonctionnant toujours sur mysql)

Le code est hébergé sur Google code. S'il vous plaît consulter le code Google pour plus d'informations

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

0
ajouté

C'est une très vieille question, mais beaucoup essayent de résoudre cela même maintenant. Tout ce qu'ils ont à faire est de faire des recherches sur les 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.

0
ajouté

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

  • Système de contrôle de version centralisé - un système standard où les utilisateurs s'enregistrent / s'enregistrent avant / après avoir travaillé sur des fichiers, et les fichiers sont conservés dans un serveur central unique

  • 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 tombe en panne, tout référentiel cloné peut être utilisé pour le restaurer Après avoir choisi le bon système pour vos besoins, vous devez configurer le référentiel qui est au cœur de chaque système de contrôle de version. Tout ceci est expliqué dans l'article suivant: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/

Après la mise en place d'un référentiel, 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 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
0
ajouté

I would suggest using comparison tools to improvise a version control system for your database. A good alternative are xSQL Schema Compare and 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 snapshots xSQL du schéma et ajouter ces fichiers dans votre contrôle de version. Pour revenir à une version spécifique ou la mettre à jour, 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 avoir les données 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é 'Revert', 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é 'update', vous devrez générer des scripts de changement 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

Disclaimer: Je suis affilié à xSQL.

0
ajouté