Options
Managing database references in SQL Source Control
Cloan1
Posts: 1 New member
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?
Tagged:
Answers
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.
DevOps Mentor and Coach
Director of DLM Consultants
Creator of Speaking Mentors
Microsoft Data Platform MVP
Friend of Redgate
Twitter / LinkedIn
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.