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

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
        ...
    ...

我所说的“这个”是指一个脚本目录(按对象类型分隔)，它表示用于启动数据库的当前/最新 版本的创建脚本。

出于某种原因，我真的很喜欢这个想法，但我无法具体证明它的必要性。我错过了什么吗？

优点是:

• 对于开发和源代码控制，我们将采用与以往相同的每个文件对象设置
• 对于部署，我们可以通过运行 Initial+Migrate 或从 Current/运行脚本将新的数据库实例启动到最新版本
• 对于开发人员，我们不需要为了进行开发而运行数据库实例。我们可以在 Current/文件夹上进行“离线”开发。

缺点是:

• 对于每个更改，我们需要更新 Current/文件夹中的脚本，并创建一个迁移脚本(在 Migration/文件夹中)

在此先感谢您的任何意见!

Answer 1

其实这是最好的办法。尽管听起来很麻烦，但它比使用 SQL Compare 之类的工具或 VSDB .schema 文件部署的替代方法要好。一段时间以来，我一直在争论 smae 方法:Version Control and your Database .我的应用程序从初始脚本部署 v1 架构，然后为每个版本运行升级脚本。每个脚本都知道如何从版本 N-1 升级到 N，仅此而已。最终结果为当前版本。

最大的缺点是缺少权威的 .sql 文件，太过寻找任何对象(过程、表、 View 等)的当前版本。但是，与任何以前的版本相比，能够部署您的应用程序的优势，以及通过受到良好控制和测试的脚本部署的优势远远超过了缺点。

如果您对使用此部署过程(部署 v1 的脚本，然后应用 v1.1，然后 v1.2 ... 直到最后应用 v4.5，当前版本)感觉不好，请记住:完全相同process 由 SQL Server 在内部用于在版本之间升级数据库。当您附加一个较旧的数据库时，您会看到著名的“数据库正在运行从版本 611 到 612 的升级”，并且您会看到升级一步一步，不会直接升级到当前版本 651(或您当前的任何情况)。升级也不会运行 diff 工具来部署 v.651 而不是 v.611。这是因为最好的方法是您只使用的方法，一次升级一个步骤。

并在发布一个相当倾斜的咆哮之后为您的问题添加一个实际答案(我对这个话题有强烈的看法，你能告诉我吗？):我认为拥有当前版本的脚本版本很有值(value)，但是我认为它应该是一个连续的集成构建过程可交付成果。换句话说，您的构建服务器应该构建当前数据库(使用升级脚本)，然后作为构建步骤，编写数据库脚本并使用当前版本模式脚本生成构建删除。但是这些应该只用作搜索和代码检查的引用，而不是作为部署交付物，我的 2C。