1. Accueil
  2. Question et réponse
  3. Fichiers de script personnalisés dans le projet serveur VS2012 Sql

Fichiers de script personnalisés dans le projet serveur VS2012 Sql

2014-07-11 5 views
0

Je suis supposé migrer une base de données dans un projet serveur VS2012 sql. J'ai déjà importé tout le schéma de la base de données cible. Les données de départ seront ajoutées au script de post-déploiement dans le projet. Cependant, je prévois également beaucoup de scripts ajoutés par les développeurs tout en travaillant sur diverses améliorations. Ceux-ci peuvent être des scripts de modification de schéma ainsi que des données ajouter des scripts de suppression d'édition. Et tous doivent exécuter post-déploiement et dans un ordre, idéalement par les noms de script avec 1.0.0.0 exécutant suivi de 1.0.0.2, puis par 1.0.1.0. Le projet SQL Server n'autorise pas plusieurs fichiers après le déploiement. Tout ce que je peux trouver en ligne est de savoir comment créer un projet alors que personne ne parle de créer une structure qui prendra en compte les changements (altérer les scripts) faits par les développeurs au cours de différents cycles de publication. Quelqu'un peut-il m'aider s'il vous plaît ici?Fichiers de script personnalisés dans le projet serveur VS2012 Sql

Source

2014-07-11 BatNetMan

+1

Afin d'utiliser plusieurs scripts de post-déploiement, vous devez marquer votre script post-déploiement principal comme "post-deploy" pour le type de construction, puis dans ce script vous utilisez le ": r. \ Script.sql "Syntaxe sqlcmd pour inclure les scripts réels. Cependant, comme l'a noté Keith, vous devriez laisser le projet gérer les changements de schéma dans 99% des cas. C'est ce que ça a été conçu pour faire. Rarement, vous devrez peut-être modifier un schéma dans un script post-déploiement, mais jusqu'à ce que cela devienne nécessaire, j'essaierai de l'éviter. –

+0

Oui, le besoin d'un script de mise à jour de schéma post-déploiement devrait être très rare. Avez-vous vraiment besoin? Si oui, pouvez-vous donner un exemple? –

+0

Plus que la mise à jour du schéma, les scripts de mise à jour d'insertion de données multiples m'inquiètent. Les données de base pour les tables augmenteraient à mesure que le produit augmenterait sa fonctionnalité. Par exemple, si je crée un système de gestion de prêts, je créerais le statut d'un prêt (InProcess, Rejected, Granted) dans une table. De même, pour chaque amélioration/histoire sur laquelle on travaille, il peut être nécessaire d'avoir des données de départ dans le système. Je suis incapable de comprendre comment cela serait pris en charge. Sûrement mettre toutes ces données dans un script de post-déploiement n'est pas une bonne idée. – BatNetMan

Répondre

1

Schema Comparison supprime le besoin de coder vos propres scripts alter. Schema Comparison crée automatiquement le script alter pour vous en comparant le schéma du projet de base de données à votre serveur de base de données.

Voici une bonne walk-through of Schema Comparison.

Source

2014-07-11 14:02:23 Keith

+0

Merci Keith, je pense que cela résoudrait mon problème de scripts de schéma. Cependant, je suis à une solution concernant la gestion des scripts de données. Tout système nécessite des données de départ et la même chose augmente au fur et à mesure que le nombre de fonctionnalités augmente. Comment vais-je gérer ces scripts.Ces scripts de données doivent également être versionnés car il est nécessaire d'avoir la possibilité de sortir du code source du code source en fonction d'une version particulière. – BatNetMan

+0

Malheureusement, VS ne fournit pas une solution directe. Je pense que l'approche la plus courante consiste à créer un script de post-déploiement qui insère les données de départ. Vous pouvez également insérer des données de départ dans votre Entity Framework/autre niveau ORM. – Keith

0

Ok, voici ce que j'ai fait jusqu'ici.

  • Suivi des entrées de Keith et a créé un projet
  • schéma utilisé comparer pour traiter le schéma des changements basés
  • créé un seul script maître avec Build Action = PostDeploy
  • Pour les scripts de données, créé des dossiers nommés comme versions pour séparer les scripts basés sur différentes versions
  • Ajout d'une entrée de ces scripts dans le script de post-déploiement maître avec la syntaxe suivante: r Folder \ MyScript.sql

Cela fonctionnerait pour le moment, mais il devrait y avoir une meilleure façon de s'assurer que les scripts personnalisés dans les dossiers sont automatiquement récupérés dans le script de post-déploiement maître. Avec cette solution, chaque fois qu'un script est ajouté par le développeur, une entrée doit être faite dans le script de déploiement Master (: r MyCustomeDataScript.sql)

Je pense qu'il y a peut-être une meilleure façon de le faire, mais je Je ne suis pas au courant. Je travaille pour trouver un moyen d'automatiser l'entrée manuelle de nouveaux scripts dans le script de déploiement principal.

Source

2014-07-14 08:46:19 BatNetMan

+0

Vous pouvez envisager un produit tel que la comparaison des données SQL de Red-Gate pour cela. Si vous pouvez conserver une copie "maîtresse" de votre base de données avec des données quelque part, vous pouvez l'utiliser pour générer le script "seed". Je ne sais pas combien de versions vous devez prendre en charge, mais vous pourriez peut-être simplifier un peu ces scripts si vous ne supportez pas beaucoup de versions. Cependant, vous devez disposer de la discipline nécessaire pour que ces scripts d'insertion de données soient archivés et utilisés. (pas nécessairement mauvais car cela garantit qu'ils ne sont pas manqués lorsque vous relâchez, mais peuvent être fastidieux) –

Questions connexes

 Questions connexes