My company has just gone though its annual review process, and I have finally convinced them that it is time to find a better solution to manage our SQL schema/scripts. Cur
We use LiquiBase to keep control of database changes:
Liquibase is an open source (Apache 2.0 Licensed), database-independent library for tracking, managing and applying database changes.
Red Gate SQL Source Control is working to support additional source control systems. If you're interested in Perforce support, please vote/comment on https://redgate.uservoice.com/admin/forums/39019-sql-source-control/suggestions/863715-support-perforce-, which we will update when/if support becomes available.
We require all database changes or inserts to things like lookup tables to be scripted and stored in source control. They are then deployed the same way any other code for a version of the software is deployed. Since our developers do not have the rights to deploy, they have no choice but to create the scripts.
I am usually use MS Server Management Studio for managing sql, working with data, developing databases and debug its, if i need to export some data as sql script or i need to create some difficult object in database, i use EMS SQL Management Studio for SQL Server, because there I can more clearly see the narrow sections of my code and visual design in this environment gives me easier
I don't think there is a tool that can handle all the pieces. VS Database Edition falls short of offering a decent release mechanism. Running individual scripts from the solution explorer does not scale well in larger projects.
At a minimum you need
The last bullet is where things usually break down. Here is why. For better managability and version tracking, you want to keep each db object into its own script file. I.e. each table, stored procedure, view, index, etc has its own file.
When something changes, you update the file, and you have a new version in your repository with the information that you need. When it comes to bundling a number of changes into a release, dealing with individual files can be cumbersome.
2 options that I have used:
In addition to keeping all the individual database objects in their files, you have release scripts that are a concatenation of the individual scripts. The downside of this: you have code in 2 places, with all the risks and disadvantages. The upside: running a release is as simple as executing a single script.
write a little tool that can read script metadata from a release manifest and execute eadch script that is listed in the manifest on the target server. There is no downside to this, except that you have to write code. This approach does not work for tables that can't be dropped and recreated (once you are live and have data), so for tables you will have change scripts anyways. So in reality, this will be combination of both approaches.
I'll link to other answers I gave to other questions related to Source Control for databases
Is RedGate SQL Source Control for me?
Exposing SQL Server database objects as files in a file system