0

Est-il possible pour moi d'avoir un projet de base de données pour maintenir "seulement" une liste sélective d'objets DB ou de scripts plutôt que d'importer la base de données entière/entière?L'utilisation de SSDT permet-elle de ne conserver que des scripts/objets sélectifs plutôt que de conserver la totalité de la base de données?

Je suis chargé d'écrire une intégration entre 3 - 4 applications tierces. Ces applications ont leurs propres bases de données SQL. Tout ce que j'ai à faire est d'ajouter quelques nouvelles tables, écrire quelques nouvelles procédures stockées, des déclencheurs et des UDF.

Voici les choses que je suis à la recherche:

Une solution automatisée pour le contrôle du changement, la maintenance et le déploiement de ce sous-ensemble d'objets DB. (J'utilise déjà TFS, donc le contrôle de source n'est pas un problème.)

Est-ce que cela peut être fait en utilisant SSDT?

Sinon, existe-t-il d'autres options open source?

Répondre

1

Vous pouvez le faire mais ce n'est pas vraiment idéal/si vous pouvez mettre tous vos objets dans leur propre schéma, alors ce serait un peu plus facile mais encore un peu pénible. J'ai travaillé dans un scénario similaire et je viens de mettre le code de tout le monde dans le projet de base de données - quand ils font une mise à jour vous synchronisez de la DB à votre projet et tant que ce n'est pas régulier .

Si vous pouvez mettre tout dans votre propre schéma et vous ne pouvez vraiment pas mettre leur code dans votre projet de base de données, puis utiliser mon filtre et ignorer tous leurs schémas (https://the.agilesql.club/Blogs/Ed-Elliott/HOWTO-Filter-Dacpac-Deployments)

Enfin, s'il est à quelques objets alors je ne serais probablement pas déranger avec ssdt - ma règle de base pour utiliser ssdt est que vous allez changer les objets régulièrement ou vous voulez une bonne validation, alors il ne vaut probablement pas la peine.

Vous avez probablement remarqué les probablies là-dedans, pas tous les cas sont les mêmes.

Désolé était un peu d'une randonnée!

Ed