Database Change Management - Setup for Initial Create Scripts, Subsequent Migration Scripts

泪湿孤枕 提交于 2019-12-04 06:32:16

Actually, this is the best way. As cumbersome as it may sound, it is better than the alternatives of using SQL Compare like tools or VSDB .schema file deployment. I have argued for exactly the smae approach for some time now: Version Control and your Database. My apps deploy the v1 schema from the initial script, then run upgrade script for each version. Each script know how to upgrade from version N-1 to N, and only that. Final result is the current version.

The biggest draw back is lack of an authoritative .sql file too look to find the current version of any object (procedure, table, view etc). But the advantages of being able to deploy your app over any previous version, and the advantage of deploying by well controlled and tested scripts far outweigh the drawback.

If you feel bad for using this deployment process (script to deploy v1. then apply v1.1, then v1.2 ... until finally you apply v4.5, current) then keep this in mind: exactly the same process is used by SQL Server internally to upgrade the database between releases. When you attach an older database, you see the famous 'database is running the upgrade from version 611 to 612' and you see that the upgrade goes step by step, does not upgrade straight to current version 651 (or whatever is current in your case). Nor does the upgrade runs a diff tool to deploy v 651 over v. 611. That is because the best approach is the one you just use, upgrade one step at at time.

And to add an actual answer to your question, after posting a rather oblique rant (Is a topic I have strong opinions about, can you tell?): I think is valuable to have a scripted version of the current version, but I think it should be a contiguous integration build process deliverable. In other words, your build server should build the current database (using the upgrade scripts) and then, as a build step, script out the database and produce a build drop with the current version schema script. But those should be only used as a reference for searching and code inspection, not as a deployment deliverable, my 2C.

I think it will just make things more complex in the long run. Whole versions need to live in a single script so that you can test that script in one context and know it will work correctly in another context like production.

Martin,

If you're in the real world, then your production database only accepts updates - you never "create" it from scratch. So the most important thing for you to be storing, watching, reviewing, etc. is the set of update scripts. Those are the scripts that will make it to production, so those are the only ones of real importance.

You're doing the right thing by making them primary. But developers needs to be able to get a "current picture" of what the schema looks like. DBAs like to do this, too, although (too) frequently they do it by logging in to the production servers and firing up some kind of gui tool. (yikes!)

The only reservation I have about your approach is the current/previous schema by object type. Those scripts should be generated automatically, from dumping the database itself. If you can automatically categorize them by type, then great! If not, do what you can to make them easy to navigate, but the guiding rule should always be "generated automatically from a live database."

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!