Having a database under source control brings huge benefits. Therefore, we decided to review and compare two popular version control tools, dbForge Source Control add-in for SSMS and Visual Studio Version Control, to help you pick a tool that meets your needs best.
A version control system allows a team to work on the same database objects, share code changes among team members, and track the history of database versions. All of these factors contribute to database development efficiency and provide database stability.
However, it is important to choose a tool that satisfies your development needs and meets your company’s requirements. So without further ado, let’s plunge into a comparison of the two tools currently popular on the market.
Managing Database Objects
First and foremost, let’s mention the most striking difference between dbForge Source Control and Visual Studio Version Control. Notably, dbForge Source Control, unlike its counterpart, allows working directly with database objects, whereas VS Version Control allows working with files only.
This means, if you want to make changes to a particular database object in Visual Studio, you need to make changes to the file directly, generate a script with the changes, save the script with a correct name, and also change the dependent objects. And only after that, you get the possibility to version control your changes. Which is much work that can be avoided.
With the dbForge Source Control add-in, you can modify the objects, and let the tool do all the job for you. It decides on what changes are necessary for you by comparing the current state of the database with the version in source control. This allows you to see the changes at once and analyze the results. Besides, you don’t have to worry about dependent objects.
Therefore, when it comes to managing database objects, dbForge Source Control is a clear winner as it helps you focus on what’s important and automate routine tasks.
Handling Static Data
A database is primarily used by us to store and access data. That is why when version controlling a database, it is not only important to keep track of changes in schema objects but also consider the database static data.
In that respect, again, dbForge Source Control takes precedence over Visual Studio Version Control. It allows version-controlling static data. Static data, also known as lookup data, represents a set of predefined values that are rarely changed and usually stay fixed. For instance, country or city names, zip codes, names of departments within a company.
However, it is important to version-control static data. The reason is static data is critical to proper database processing. It plays a key role in most database transactions. It is of great importance to know who, when, and why updated static data. Version controlling enables us to do that.
Within dbForge Source Control, you can easily link your static data to version control, commit any changes, and resolve conflicts if necessary. Plus, you can see the changes in the data grid that is somewhat similar to an Excel spreadsheet.
Integration with Version Control System
Both tools support the most widely-used modern version control system, Git, as well as cloud-based solutions, such as GitHub, GitLab, BitBucket, and Git in Azure DevOps in addition to TFVS in Azure DevOps. However, Source Control has larger integration capabilities that come out of the box. It can also link your database to the following version control systems:
- Apache Subversion (SVN)
- Mercurial (Hg)
- Perforce (P4)
- SourceGear Vault
This said, Visual Studio Version Control provides a rich selection of extensions, including those that refer to the above-mentioned version control systems, that can be integrated into the tool. So, in this respect, although Source Control has its obvious benefits, both tools strive to provide the user with a range of integration choices making it easy to link to any VCS.
Working with Git
Here, we should talk more about the Git version control system as it has won the hearts of millions of users. Visual Studio Version Control introduced an improved Git experience, which incorporates several new features allowing users to use Git more simply and effectively.
First, it became really easy to initialize a local Git repository and push it to GitHub or Azure Repos. Also, they implemented a new Git menu and Git tool window allowing users to create and manage branches as well as commit code changes with just a few clicks. Thus, we may conclude that Visual Studio Version Control has made considerable progress and outperformed its counterpart in this respect.
Managing Local Folder
It is often necessary to link your database to a local folder that was created with a third-party tool. Let’s see how both tools accomplish this task.
dbForge Source Control has a working folder feature. A working folder comprises a pack of SQL script files that represent your database. The tool allows you to source-control a SQL database working folder with your version control system in the same way as you version-control other files.
In the Source Control Manager, you can view the changes on the grid, commit them or revert, or identify the owner. The Manager allows you to view the differences between the local and remote copies highlighted in different colors.
Unlike Source Control, Visual Studio Version Control doesn’t provide the same feature. However, it has the Workspace Mapping option that allows you to map your entire project to a local folder and then keep track of the changes in this folder. The option is available under the advanced Source Control options.
Managing History of Changes
When using a version control system, it’s essential to keep the history of changes and know who introduced them and when. Having a complete history of changes allows you to return to older versions, compare the differences between the versions, and troubleshoot any issues.
This feature is incorporated in both tools. Using both tools you can do the following:
- View details of each commit, including date, author, and comment
- Check a list of code changes introduced with each commit
- Compare the local version with the remote one
However, the dbForge tool has a significant advantage because, among other things, it also allows to:
- View the changes history for the entire database or for separate objects
- Check the differences in database objects and not files
- Identify DDL differences for each database object
Hence, dbForge Source Control wins a few extra points in this respect.
Database Development Models
There are two main database development models, a shared and a dedicated one. While version controlling your database, it is important to have an opportunity to choose between the two of them.
Within dbForge Source Control, you can opt for either of the two database development models. Choosing a development model helps establish the most convenient working environment where you can adjust the database development process to your teams’ needs best.
The dedicated model allows developers to work independently on their local copies and then push changes to a central repository. Using this model, a developer can test the changes locally and prevent his push from breaking the code of other developers.
Compared to that, a shared model implies that the team works on the same database copy. This development model allows the team to check the latest updates as soon as they arrive. However, within this model, a developer can easily overwrite the changes made by other team members, so one has to be really careful.
VS Version Control doesn’t provide a similar feature for version-controlling databases.
Handling Conflicts
When a team of developers works on a project and commits their changes, it is unavoidable for conflicts to happen. Both tools deliver functionality that allows identifying and resolving conflicts in a convenient way.
Visual Studio provides a Merge Editor that represents a three-way merge tool displaying the incoming changes, your current changes, and the result of the merge. Using the interface, you can select to accept all changes from one side or the other as well as select to accept individual changes from either side.
In dbForge Source Control, conflicts are displayed in the Conflicts section of the Source Control Document. To resolve a conflict, you can click Get Local to override remote changes with your local ones or Get Remote if you want to accept the remote changes.
Besides, the Source Control Document displays DDL diffs for the conflicts so that you can clearly see the reason for the conflict.
Conclusion
To summarize, the two tools under comparison have their benefits and flaws. However, dbForge Source Control is clearly more convenient when it comes to version controlling a database and the objects it contains. Conversely, Visual Studio Version Control is probably more applicable to managing files. Besides, Visual Studio is a great IDE often used for writing and editing code.
