The whole idea of the VSTS database is to set you on the right path, i.e. store definitions of database objects as .sql files, and not as some kind of fancy diagram. Any modification you make to the objects you do by modifying the definition of SQL. Thus, you can make any changes to objects, as allowed by the DDL syntax, as opposed to what you think the visual designer du-jour cannot do. Not to mention the many SQL code generation errors associated with all designers.
Closing a visual representation is a diagram representation that displays tables, columns, indexes, etc. in a tree view, and you can see the properties from there.
By focusing the development process and the Visual Studio project on .sql source files, teams can collaborate in developing the database using proven and proven version control methods (check-out / check-in, lock file, conflict detection and merge integration, branching, etc.). d.).
The output from the VSTS DB project is a .dbschema file that can be deployed to any server using vsdbcmd . This is an intelligent deployment that synchronizes the circuit (merging a new object, modifies existing ones) and can detect and prevent data loss during deployment. In contrast, the “classic” way to do this (from VS Server eExplorer or from SSMS) was the MDF file itself, the database itself, as the supplied product. This creates huge deployment problems. Deploying v1 is really smooth (just copy the MDF done), but as soon as you want to release v1.1, you are stuck: you have a new MDF, but the production runs on its own MDF and does not work, you want to replace it with your own, as this means data loss. Now you turn around and want you to have some kind of history of deploying a version of the database schema, and that's exactly what VSTS DB does for you from day 0.
Remus Rusanu
source share