Managing database references in SQL Source Control

How does SQL Source Control manage database references among databases (i.e. DatabaseA has a view referencing a table in DatabaseB)? Microsoft uses DacPacs. The issue is there is no mechanism for fetching referenced artifacts (dacpacs or whatever) which are controlled by a different team. Visual Studio uses nuget for .Net code. Does SQL Source Control provide this type of functionality?

Answers

  • AlexYatesAlexYates Cambridge, UK Posts: 263 Rose Gold 2
    edited November 8, 2019 9:36AM
    It doesn't.

    This is both a good thing and a bad thing. For example, SSDT gives you great build output based on your cross-DB dependencies, but they also become almost impossible to manage.

    With the Redgate approach it is far easier to decouple your source control projects and work on them in manageable chunks. Then you can pickup on broken database dependencies by running your builds on an integration server instance. This still gives you the fast feedback, but enables far simpler database development. However, it comes with the cost of maintaining a persistent integration environment.

    Obviously, the ideal solution, is to work towards a more loosely coupled architectiure, avoiding direct dependencies between databases where possible.
    Alex Yates
    DevOps Mentor and Coach

    Director of DLM Consultants and Data Relay
    Creator of Speaking Mentors
    Microsoft Data Platform MVP
    Friend of Redgate
    Twitter / LinkedIn
  • way0utwestway0utwest CO, USA Posts: 307 Rose Gold 1
    Kendra has a view on some of this here: https://www.youtube.com/watch?v=20xJTUokUxM&t=1s

    You can work with the objects, database by database, and certainly commit from each one. The challenge with deployment is understanding where the dependencies exist and which order in which to deploy changes. For builds, you likely want all databases o the build server, and then deploy to a new name for each to test the changes.

Sign In or Register to comment.