数据库更改管理 - 初始创建脚本,后续迁移脚本的设置

Question

我已经有了数据库变更管理工作流程.它基于SQL脚本(因此,它不是基于托管代码的解决方案).

基本设置如下所示:

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

启动数据库的过程是运行所有Initlal脚本,然后运行顺序迁移脚本.一个工具可以考虑版本控制要求等.

我的问题是,在这种设置中,保持这个是有用的:

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

"this"是指脚本目录(由对象类型分隔),表示用于旋转当前/最新版本数据库的创建脚本.

出于某种原因,我非常喜欢这个想法,但我无法具体证明它的需要.我错过了什么吗？

优点是:

• 对于开发和源代码控制,我们将拥有与以前相同的每个文件对象设置
• 对于部署,我们可以通过运行Initial + Migrate或从Current /运行脚本来将新数据库实例启动到最新版本
• 对于dev,我们不需要运行数据库实例来进行开发.我们可以在Current /文件夹上进行"离线"开发.

缺点是:

• 对于每个更改,我们需要更新Current /文件夹中的脚本,以及创建Migration脚本(在Migration /文件夹中)

提前感谢任何输入!

Answer 1

实际上,这是最好的方法.虽然听起来很麻烦,但它比使用SQL Compare工具或VSDB .schema文件部署的替代方案更好.我已经争论了一段时间的确切方法:版本控制和你的数据库.我的应用程序从初始脚本部署v1架构,然后为每个版本运行升级脚本.每个脚本都知道如何从版本N-1升级到N,只有那个.最终结果是当前版本.

最大的缺点是缺乏权威的.sql文件,以查找任何对象的当前版本(过程,表,视图等).但是,能够在任何先前版本上部署应用程序的优势,以及通过良好控制和测试的脚本进行部署的优势远远超过了缺点.

如果您对使用此部署过程感到不舒服(脚本部署v1.然后应用v1.1,然后v1.2 ......直到最后应用v4.5,当前),请记住:完全使用相同的过程由SQL Server在内部升级版本之间的数据库.附加较旧的数据库时,您会看到着名的"数据库正在运行从版本611到612的升级",您会看到升级是一步一步进行的,不会直接升级到当前版本651(或者是您当前的任何版本) ).升级也不会运行差异工具来部署v 651而不是v.611.这是因为最好的方法是你刚刚使用的方法,一次升级一步.

并且在发布一个相当倾斜的咆哮之后添加一个实际的问题答案(这是一个我有强烈意见的主题,你能说出来吗？):我认为有一个当前版本的脚本版本是有价值的,但我认为它应该是一个连续的集成构建过程可交付成果.换句话说,构建服务器应该构建当前数据库(使用升级脚本),然后,作为构建步骤,编写数据库脚本并使用当前版本模式脚本生成构建删除.但那些应仅用作搜索和代码检查的参考,而不是用作部署可交付成果,我的2C.