I've just inherited an SQL Server database. One of the things I will need to sort out is versioning and automated builds.
It has been suggested that I should think seriously about recommending RedGate SQL Compare, but I have to admit I am a little uneasy about it.
My reservations are...
- it appears to promote use of the gui tools for db work?
- for live apps, I prefer to work with change scripts, this avoids the last minute panic to create migration scripts at the end of each scrum cycle, and it means your update scripts can be tested by the CI. I can't see how the RedGate tool addresses this.
My gut instinct tells me to stick with the tried and tested approach of an MSBuild file and a stack of .SQL files.
I would be interested to hear if anyone has any experience on using this tool.
We use Red Gate to generate scripts for deployment and to control versioning.
"Deployment" and "versioning" are separate issues for SQL code.
Important to note: your production database is master with all it's data. So arrange of regular copies to a test server and use this as a baseline. A database generated by NUnit every night with basic data (seen it, had a laugh) is generally useless. What if you have a billion rows and need to test a query against it?
Versioning: You can use the Red Gate tools to generate a schema as a baseline and then compare this to this copy (or your QA or whatever). The Red Gate tools allows comparison to a folder, which is under SVN control in our case and is updated every release. So we have full history of every object
Deployment: we apply our development scripts (also in SVN) against a clean "build" DB and compare to another clean DB. This becomes our deployment script.
This is quite simplified of course.
The pro version offers an API to synch and compare so you can integrate into your tool chain if needed. No GUI needed. Incidently, we use this to provide a one click synch of some special user sandboxes complete with client code.
As Remus mentioned, they aren't foolproof for some operations. If you are changing stuff on 1.5TB tables, I'd lovingly handcode my script. Another irritation is that Red gate's tool has a habit of dropping SCHEMABINDING on a related view or udf for a simply check constraint change.
I also recommend reading Martin Fowler's "Evolutionary Database Design" for some inspiration
I'd prefer scripts as well -- easy to store in source control (CVS, Git, etc) so you can diff to see when changes were made.
I don't trust diff based tools for deployment. And that includes vsdbcmd .schema files, since they are also diff based. Last time I tried to use a diff tool it joyfully offered to change a 1.5 TB table via copy/drop/rename...
My approach is to always use upgrade scripts that move the deployed schema from v. N to v. N+1. This way I know exactly how is the upgrade done, and if an operation is not possible (it would require a size-of-data copy operation lasting 2 weeks...) then I know I cannot do it and I plan my code changes for the release of v. Next accordingly.
I have an open-source (licensed under LGPL) toolset project which tries to address the issues related to proper DB schema versioning for (and more) SQL Server (2005/2008/Azure), the bsn ModuleStore.
Basically, the standalone part of the toolset scripts the SQL Server DB objects of a DB schema into files with a standard formatting applied, so that the file contents only changes if the object really did change (very much in contrast to the scripting done by VS, which scripts some scripting date etc. as well, marking all objects as changed even if they are in fact identical).
But the toolset goes beyond that if you use .NET: it allows you to embed the SQL scripts into the library or application (as embedded resources) and then have it compare the embedded scripts with the current state in the database. Non-table-related changes (those that are not "destructive changes" as per Martin Fowler's definition) can be applied automatically or on request (e.g. creating and removing objects such as views, functions, stored procedures, types, indexes), and change scripts (which need to be written manually though) can be applied in the same process as well; new tables are also created, optionally along with their setup data. After the update, the DB schema is again compared against the scripts in order to ensure a successful DB upgrade before the changes are committed.
Note that the whole scripting and comparison code works without SMO, so that you don't have the painful SMO dependency when using the bsn ModuleStore in applications.
Depending on how you want to access the database, the toolset offers even more - it implements some ORM capabilities and offers a very nice and useful interface-based approach to invoke stored procedures, including transparent support for XML with native .NET XML classes and also for TVPs (Table-Valued Parameters) as IEnumerable<PocoClass>.
SQL Compare can either generate a SQL migration script that can be independently reviewed before applying it, but also gives the option to execute the script within the tool. Red Gate recommends using the former method when deploying to production databases.
For database versioning, SQL Source Control support most source control systems (eg, SVN, TFS, etc, although VSS support has been deprecated). There is, in v3, an option to link to a working folder, allowing you to use your own version control client if desirable.
We use a compare tool as part of our deployment process to see if anything needing a script is missing and then go discuss it with the developer if so (usually it is a differnce that isn't checked in to the deplyment location because it shouldn't be moved to go to prod). But we deploy from scripts that are in source control always. If you rely on SQL Compare or any other compare tool, you may find yourself moving things that should not yet be moved.
来源：https://stackoverflow.com/questions/4432768/is-redgate-sql-source-control-for-me