Quelle est l'approche suggérée pour la synchronisation/sauvegarde/restauration de SQL Server 2008 vers SQL Server 2005 ?

Question

Je n'ai que SQL Server 2008 (Dev Edition) sur ma machine de développement.

Je ne dispose que de SQL Server 2005 chez mon hébergeur (et je n'ai pas d'accès direct à cette base de données).

Je me demande juste quelle est la meilleure approche à adopter :

1. Mise en production de la structure et des données de la base de données initiale.
2. Et maintenir la synchronisation de tout changement structurel/changement de données à l'avenir.

Pour autant que je puisse voir...

• Réplication - pas une option car je ne peux pas me connecter à la base de données de production.

• La restauration d'une sauvegarde n'est pas une option car, d'après ce que je vois, il n'est pas possible d'exporter une base de données de 2008 qui peut être restaurée en 2005 (même avec la base de données de 2008 définie en mode de compatibilité 2005) et cela n'aurait aucun sens de restaurer la production par-dessus ma version de développement.

• Vider tous les scripts de ma base de données 2008, inverser mon Dev to machine de 2008 -> 2005, et recréer la base de données à partir des scripts, puis juste utiliser la sauvegarde et la restauration pour obtenir la base de données initiale en production, puis exécuter les scripts à travers le panneau web à partir de ce point.

• Vider tous les scripts de ma base de données 2008 et générer l'ensemble de la db 2005 à partir de scripts en production. puis exécuter scripts à travers le panneau Web à partir de ce point.

• Avec les 2 dernières options, j'aurais probablement besoin de script toutes les insertions de données aussi en utilisant un outil (qui je présume existe sur le web)

Y a-t-il d'autres solutions possibles que je n'ai pas envisagées ?

Answer 1

En le plus sûr L'option la plus simple serait de rétablir votre environnement de développement en SQL 2005, car de cette façon, quoi qu'il arrive, votre code sera compatible avec votre environnement d'hébergement. Vous devriez pouvoir installer une instance 2005 distincte sur votre boîte, ce qui devrait vous faire gagner du temps (n'ayez qu'une seule instance 2005/2008 active à la fois pour des raisons de performances). Pour obtenir cette configuration, vous devrez peut-être désinstaller 2008, puis installer une instance 2005, puis installer une instance 2008.

En ce qui concerne les données, vous pouvez utiliser l'utilitaire BCP pour copier des données dans et hors de la base de données. Une fois que vous l'avez pris en main, il est assez rapide et pratique.

Answer 2

C'est parce que votre livrable de développement est une base de données MDF au lieu de sources script. la bataille est déjà perdue. Outre la différence de version initiale du moteur de déploiement, vous aurez d'autres problèmes dès que vous tenterez de déployer votre première mise à jour de l'application. Vous vous retrouverez à essayer d'appliquer un delta du schéma en production, ce qui n'est pas une mince affaire. Vous finirez probablement par utiliser des outils comme SQL Compare ou quelque chose de similaire. Et ceci même maintenant, lorsque vous avez 1 (un) développeur et 1 (un) serveur de production. Si vous ajoutez d'autres développeurs ou d'autres déploiements, les choses ne font qu'empirer.

Mais il y a de meilleurs moyens.

L'un des moyens consiste à utiliser un outil de développement basé sur les sources, comme Visual Studio Database Edition. Le résultat d'un projet VSDB est un .dbschema qui peut être déployé en tant que diff delta dans la production à l'aide de l'outil de développement VSDB. vsdbcmd outil.

Un moyen encore meilleur est de versionner votre schéma et de tout déployer par la mise à niveau scripts de la v. N à la v. N+1. Voir Le contrôle de version et votre base de données .

Les deux approches fournissent, en plus d'un chemin de déploiement gérable, une version de contrôle de source de vos changements de schéma de base de données.

Il est vrai cependant que même avec une approche basée sur script vous pouvez vous retrouver avec des fonctionnalités 2008 dans votre script et avoir une surprise au moment du déploiement, un outil comme VSDB peut effectivement les attraper pendant la construction/compilation. Même si vous faites une erreur, il est facile de récupérer en modifiant les script, par opposition à repartir de zéro sur une nouvelle base de données vide de la bonne version rétrogradée.

Answer 3

Vous pouvez exécuter les instances 2005 et 2008 (et plusieurs instances de chacune d'entre elles, en fait) sur votre machine de développement (comme vous l'avez mentionné, vous pouvez également exécuter les bases de données en mode de compatibilité 2005 dans 2008, ce qui n'est vraiment utile que pour désactiver les fonctionnalités de syntaxe). Je vous le recommande, puisque vous avez dit que vous aviez la possibilité de revenir à l'installation de 2005 - il suffit d'exécuter les deux en parallèle.

Ainsi, vous pourriez sauvegarder et restaurer votre hébergement sur votre machine de développement, puis utiliser un certain nombre d'outils de comparaison de bases de données (Red Gate SQL Compare ou ApexSQLDiff, par exemple) pour comparer les bases de données 2005 et 2008 sur votre machine de développement et générer des changements scripts pour les tester d'abord dans le développement, puis les appliquer à la production.