J'ai quelques questions sur le processus de travail. Récemment, je suis entré dans le nouveau projet avec de nombreuses activités de base de données impliquées. L'un de nos référentiels est le projet de base de données Visual studio et contient toutes les procédures stockées, les fonctions, etc. Nous ne l'utilisons pas pour CI, comme Azure. Si je comprends bien, nous publions tout manuellement. Les questions sont:
1) Quel est le but du projet de base de données Visual Studio? Pouvez-vous me donner quelques points à ce sujet?
2) Dois-je déboguer et exécuter tout le code SQL dans SSMS ou dans le projet Visual Studio db pendant le processus de développement?
3) Quel est le but des fonctions «publier» et «construire» qu'il contient? Sont-ils capables de casser quelque chose dans la base de données existante? Comment, pourquoi et quand les utiliser en toute sécurité?
Je serai très reconnaissant de fournir tous les didacticiels, vidéos et bonnes pratiques liés à ce thème.
3 Réponses :
1) Quel est le but du projet de base de données Visual Studio? Pourriez-vous me donner quelques points à ce sujet?
Dans l'état actuel, il est bon pour suivre les bases de données et voir les modifications. Il manque beaucoup de fonctionnalités pour générer correctement des scripts delta sur des scénarios plus volumineux (redgate a un produit pour cela qui est construit sur le dessus). Nous l'utilisons pour documenter l'état de la base de données - ce qui est pratique pour voir dans quelle mesure certaines bases de données sont distinctes de l'état documenté dans une branche particulière.
Nous utilisons un autre mécanisme pour générer des scripts de modification.
2) Dois-je déboguer et exécuter tout le code sql dans SSMS ou dans le projet Visual Studio db pendant processus de développement?
Ah, nous avons une suite de tests d'intégration très complète qui provient de l'API et exécute une tonne de SQL backend - cela nous couvre. Pas besoin de passer des jours à tester tout SQL à chaque déploiement.
3) Quel est le but des fonctions «publier» et «construire» qu'il contient?
Dites-moi si vous le savez. Je leur ai trouvé des implémentations à moitié cuites. Mais ensuite, nous faisons parfois de grandes bases de données complexes - il ne s'agit pas SEULEMENT de changer la structure de la base de données, mais de le faire d'une manière spécifique qui transforme les données, puis les insère dans les bases de données modifiées.
Ce que j'ai découvert par moments, c'est que les projets DB pouvaient déployer une nouvelle base de données contenant des données statiques - mais ensuite, nous le faisons souvent avec nos scripts de modification.
C'est vraiment à mon humble avis une tentative sérieuse, en particulier par rapport à https://www.red-gate.com/products/sql-development/sql-change-automation/ le manque de changements multi-étapes etc. le rend pas vraiment utile pour nos cas d'utilisation.
MS le fait régulièrement - c'est-à-dire que vous avez également des migrations de base de données dans EntityFramework (que nous n'utilisons pas non plus). Approches multiples à travers différents produits.
Il vaut donc mieux demander à mes coéquipiers? Je me demande simplement si cela ressemblera à une question stupide ou non.
Non, c'est plutôt la partie la moins utilisée du studio visuel. Entre toutes les façons alternatives de gérer les schémas de base de données et ses limitations internes, je dois encore voir quiconque l'utilise réellement pour plus que de la documentation (c'est-à-dire pour enregistrer le schéma de base de données dans le contrôle de code source). Voyez combien de réponses vous obtenez ici;)
J'adore ❤ ce type de projet.
Le projet de base de données vous donne plusieurs choses:
Est-ce une bonne idée de l'utiliser?
Oui. Je pense que cela devrait faire partie de tous les projets avec SQL Server.
Problèmes que j'ai rencontrés avec celui-ci:
Je l'utilise dans Visual Studio 2019.
Plus d'informations ici: docs.microsoft.com/en-us/previous-versions/sql/...
Il s'agit des outils de données SQL Server (SSDT). Si vous recherchez cette phrase sur Google, vous trouverez des dizaines de sites Web qui en discutent longuement. Je n'ai pas de site préféré pour cela - lorsque j'essaie de comprendre quelque chose, je lis plusieurs sites pour avoir une vue "composite" des choses.
L'essentiel est que SSDT fournit une méthodologie de déploiement basée sur l'état, par opposition aux méthodologies basées sur la migration plus familières. "Basé sur l'état vs basé sur la migration" est un autre bon terme pour Google - tous ces sites Web font un meilleur travail pour le décrire que je ne pourrais le décrire ici.
Build est à peu près analogue à "Will the code compile", par exemple La syntaxe est-elle bonne, ou faites-vous référence à des tables, des colonnes, des procédures qui n'existent pas. Comme il est géré dans Visual Studio, traquer et corriger ces bogues peut être très facile. Eh bien, retrouvez-les au moins.
Publier signifie essentiellement "prendre la base de données telle que définie dans le code de ce projet, la comparer à une base de données cible et faire en sorte que cette base de données ressemble à ce que nous avons dans le code". Vous insérez les définitions (table, procédure, etc.) dans, SSDT écrira toutes les instructions CREATE, ALTER et DROP nécessaires pour vous. Oui, des tonnes de problèmes s'il y a des données sur le chemin, avec diverses solutions pour les résoudre, mais vous n'avez pas à vous assurer que vos cinq années de scripts sont traitées dans le bon ordre.