Versionnement de la base de données SQL Server

Question

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

Je voudrai toujours avoir au moins un peu de dans ces données (comme alumb mentions : types d'utilisateurs et administrateurs). Je souhaite aussi souvent disposer d'une grande collection de données de test générées pour mesurer les performances.

Answer 1

Martin Fowler a écrit mon article préféré sur le sujet, http://martinfowler.com/articles/evodb.html . J'ai choisi de ne pas mettre les vidages de schéma sous contrôle de version car 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 disposerai d'une seule instance de base de données de production, j'utilise deux techniques :

Scripts de mise à jour de la base de données

Des scripts de mise à niveau de la base de données qui contiennent le DDL nécessaire pour faire passer le schéma de la version N à N+1. (Ils sont placés 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 qu'une mise à jour script s'exécute qui correspond à la nouvelle version.

Ainsi, il est facile de savoir quelle version du schéma de base de données existe et les scripts de mise à niveau de la base de données ne sont exécutés qu'une seule fois. Encore une fois, il s'agit no des décharges de la base de données. Plutôt, chaque script représente le changements nécessaires pour passer d'une version à l'autre. Ce sont les script que vous appliquez à votre base de données de production pour la "mettre à niveau".

Synchronisation du bac à sable du développeur

1. Un script pour sauvegarder, assainir et réduire une base de données de production. Exécutez ce script après chaque mise à niveau de la base de données de production.
2. Un script pour restaurer (et mettre au point, 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 à jour de la BD de production.

Une mise en garde : mes tests automatisés s'exécutent sur une base de données au schéma correct mais vide. Ces conseils ne seront donc pas parfaitement adaptés à vos besoins.

Answer 2

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 changement à 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 création [nom de l'objet].sql script par objet dans ces répertoires. La hiérarchie par type d'objet est la suivante :

\Functions
\Security
\Security\Roles
\Security\Schemas
\Security\Users
\Stored Procédures
\Tables

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

Answer 3

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

Si vous avez uniquement besoin de stocker la structure de la base de données et non les données, vous pouvez exporter la base de données sous forme de requêtes SQL. (dans Enterprise Manager : Clic droit sur la base de données -> Generate SQL script. Je vous recommande de paramétrer l'option "create one file per object" dans l'onglet options) Vous pouvez ensuite commiter ces fichiers texte dans svn et utiliser les fonctions diff et logging de svn.

Je l'ai lié à un Batch script qui prend quelques paramètres et configure 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, postez quelque chose et je peux mettre le script quelque part d'accessible).

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

Answer 4

Ici, à Red Gate, nous proposons un outil, Contrôle des sources SQL 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 à SSMS et vous permet de travailler comme vous le feriez normalement, sauf qu'il vous permet maintenant de livrer les objets.

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

Dans SQL Source Control, il est possible de spécifier des tables de données statiques. Celles-ci sont stockées dans le Source Control en tant qu'instructions INSERT.

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

Answer 5

Vous pouvez vous intéresser à 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.