Suggestions de logiciels de déploiement/mise à niveau de bases de données multiples SQL Server 2005

Question

Nous avons un produit qui utilise plusieurs bases de données SQL Server 2005 avec des déclencheurs. Nous recherchons une solution durable pour le déploiement et la mise à niveau des schémas de base de données sur les serveurs clients.

Actuellement, nous utilisons SQL Packager de Red Gate, qui semble être le mauvais outil pour ce travail particulier. SQL Packager semble non seulement être orienté vers des bases de données individuelles, mais la version (ancienne) que nous possédons a quelques problèmes avec SQL Server 2005. (Notre version de SQL Packager a bien fonctionné avec SQL Server 2000, même si nous devions faire un Beaucoup de solutions de contournement pour le faire gérer plusieurs bases de données avec des déclencheurs.)

Quelqu'un peut-il suggérer un produit qui peut créer un projet EXE ou .NET pour faire les choses suivantes?

* Create a main database with some default data. 
* Create an audit trail database. 
* Put triggers on the main database so audit data will automatically be inserted into the audit trail database. 
* Create a secondary database that has nothing to do with the main database and audit trail database. 

Et puis, quand un client a besoin de mettre à jour leur schéma de base, le produit peut regarder les changements entre l'ensemble des bases de données d'origine et l'ensemble des bases de données mises à jour sur notre serveur. Ensuite, le produit peut créer un projet EXE ou .NET qui peut, sur le serveur du client ...

* Temporarily drop triggers on the main database so alterations can be made. 
* Alter database schemas, triggers, stored procedures, etc. on any of the original databases, while leaving the customer's data alone. 
* Put the triggers back on the main database. 

Fondamentalement, nous sommes à la recherche d'un produit similaire à SQL Packager, mais qui va gérer plusieurs bases de données facilement . Si un tel produit n'existe pas, nous devrons créer le notre.

Merci d'avance pour vos suggestions!

Answer 1

Je cherchais moi-même ce produit, sachant que la solution RedGate fonctionnait bien pour une "DB"; malheureusement j'ai pu trouver cet outil :(

En fin de compte, je devais rouler ma propre solution pour faire quelque chose « similaire ». Ce fut une douleur dans la ... mais cela a fonctionné.

mon scénario était plus simple que le vôtre, que nous ne disposions pas des déclencheurs et T-SQL

Plus tard, j'ai décidé d'adopter une approche différente:...

Tout changement DB avait un SCRIPT numéroté 001_Create_Table_xXX.SQL , 002_AlterTable_whatever.SQL, etc.

Peu importe la taille du changement, il doit y avoir un script. La nouvelle version de l'Updater fait ceci:

1. Makes un BKP du customerDB (juste au cas où)
2. commence à exécuter des scripts dans l'ordre alphabétique. (001, 002 ...)
3. Si un script échoue, il supprime le BD. Consigne l'erreur de script, le numéro de script, etc. et restaure la base de données du client.
4. Si cela se termine, il fait une autre sauvegarde du DB du client (après la "migration") et met à jour une table où nous stockons la version DB; cette table est vérifiée par l'application pour s'assurer que la base de données et l'application sont synchronisées.
5. Affiche un beau succès.

Ceci s'est avéré être un peu plus "manuel" mais il a vraiment fonctionné avec peu d'effort pendant trois ans maintenant. Le secret consiste à garder quelques DB de test pour tester la "mise à niveau" avant le déploiement.Mais en dehors de quelques Dbs isolées où certains scripts ont échoué en raison d'une incohérence des données, cela a fonctionné correctement.

Comme votre scénario est un peu plus complexe, je ne sais pas si ce type d'approche peut vous convenir.

Answer 2

Au moment d'écrire ces lignes (juin 2009), il n'y a toujours pas de produit sur le marché qui permette de faire tout cela pour plusieurs bases de données. Je travaille pour Quest Software, fabricant de Change Director pour SQL Server, un autre système d'automatisation de changement de base de données. Le nôtre ne gère pas plusieurs bases de données comme vous l'êtes, et j'ai vu les autres là-bas. Pas de dé.

Je ne voudrais pas non plus espérer pour autant, étant donné les directions que j'ai vu dans la gestion de SQL Server. Les choses vont de plus en plus vers des applications emballées contenues dans une base de données unique, et la plupart du code se concentre sur cela.