Managing database references in SQL Source Control

Cloan1

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?

AlexYates

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.

way0utwest

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.