如何更新SQL Server数据库架构？

Question

Usually throughout development of a project I will deploy frequently, just to make sure I wont have any problems in production.

Also, throughout development, I find myself changing the database's schema.

How can I easily update the database in production?

I have been dropping the old database and reattaching the new one. Is there a faster way to update the deployment database?

Thanks

EDIT

What are some free tools for this?

Answer 1

Maintain a list of all the change scripts that you apply to your dev database and apply them to the Production database when deploying.

Alternatively, use a third party tool that can compare the two schemas and provide a changescript which you can then run.

Answer 2

I try to use tools like RedGate SQL Compare which will show you "diffs" between two versions and actually script out the components that are different. You can also make it a habit to script all of your database revisions so that you have an audit trail of changes you've made and can apply them in a programmatic way when you are ready to deploy.

Answer 3

Your best bet is to implement your changes as a set of diff scripts. So rather than dropping a table and recreating it, you script is as ALTER TABLE.

There are also tools out there that help you do this. If you keep a copy of the original and the new database, you can run a tool against the two which will generate SQL that will take you from one version to another.

Answer 4

I personally like to keep full creation scripts updated, as well as maintaining an upgrade script, whenever I change the schema for a particular release. I have used Red Gate SQL Compare, and it is a very good tool, but prefer to keep the scripts maintained.

Answer 5

Always write a script to make your schema changes. Place the script in a promotion folder so that when you promote your changes, the scripts are executed to change each environment.

Answer 6

Try DBSourceTools.
http://dbsourcetools.codeplex.com
Its open source, and will script an entire database
- tables, views, procs and data to disk, and then allow you to re-create that database through a deployment target.
It's specifically designed to help developers get their databases under source code control.

Answer 7

Generate Scripts向导完全符合我的需要。

Answer 8

Migrator Dot Net is an awesome tool for versioning your database. It's hard to go back to manually keeping track of scripts and doing database comparisons after you've used migrations.

Answer 9

Visual Studio Database Edition is quite good at this . It keeps your entire schema in source scripts under source control along with the rest of your code. It can analyze your schema for dependencies when you make a change. It can run best practices analysis. And it can generate a .dbschema file that can is used by the deployment tool to upgrade your database to the current schema.

You can actually automate this with continuos integration and build drops straight to test environment, staging environment and even production environment. What that means is that when you check in into the test branch, the build machine will build product, run the build validation tests and deploy it on your development server. When you reverse integrate from test branch to main branch, the build machine builds the product, runs the BVTs and deploys is on your staging test/acceptance server. And when you integrate into the release branch the build machine will build, test and finally deploy on production. Now is true, not many orgs are ready to go that far and let the continuos build process deploy automatically on the live production servers and I reckon it is kinda radical thinking. But I say you should trust more your automated BVTs and automated processes than any manual test and deployment.