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

【问题标题】：Database Change Management - Setup for Initial Create Scripts, Subsequent Migration Scripts数据库更改管理 - 初始创建脚本、后续迁移脚本的设置
【发布时间】：2011-01-31 00:20:57
【问题描述】：

我有一个数据库变更管理工作流程。它基于 SQL 脚本（因此，它不是基于托管代码的解决方案）。

基本设置如下所示：

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

启动数据库的过程是运行所有初始脚本，然后运行顺序迁移脚本。一个工具可以处理版本控制要求等。

我的问题是，在这种设置中，维护它是否有用：

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

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

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

优点是：

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

缺点是：

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

提前感谢您的任何意见！

【问题讨论】：

如果重要的话，我使用的是 Red Gate 工具堆栈（SQL Compare Pro 等），尽管我认为上述过程与工具无关。
这应该是社区维基。
如果您已经在使用 Red Gate 工具，您可能会对 SQL 源代码控制感兴趣，它可以作为早期访问版本进行尝试。请参阅red-gate.com/Products/SQL_Source_Control/index.htm 我很乐意进一步讨论您的要求并确定是否可以使 SQL 源代码控制为您有效地工作。您能否给我发电子邮件（我是 Red-gate dot com 的 David.Atkinson 的产品经理），我们可以进一步讨论这个问题吗？
它的早期访问已经结束，SQL Source Control 1.0 现已发布！ red-gate.com/products/SQL_Source_Control/index.htm

标签： sql-server database redgate dbmigrate

【解决方案1】：

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

最大的缺点是缺乏权威的 .sql 文件，也无法查找任何对象（过程、表、视图等）的当前版本。但是，与任何以前的版本相比，能够部署您的应用程序的优势，以及通过良好控制和测试的脚本部署的优势远远超过了缺点。

如果您不喜欢使用此部署过程（部署 v1 的脚本，然后应用 v1.1，然后应用 v1.2 ...直到最终应用 v4.5，当前），请记住这一点：完全相同SQL Server 在内部使用进程在版本之间升级数据库。当您附加较旧的数据库时，您会看到著名的“数据库正在从版本 611 升级到 612”，并且您会看到升级逐步进行，不会直接升级到当前版本 651（或在您的情况下是最新的）。升级也不会运行差异工具来部署 v 651 而不是 v. 611。那是因为最佳方法是您只需使用的方法，一次升级一个步骤。

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

【讨论】：

我对这种方法很感兴趣。我想这个脚本的运行时间会随着时间的推移而增加很多。您最终是否会将早期的更改“汇总”到初始创建脚本中以解决此问题？
@Dolbz：是的，但请记住，汇总意味着您中断了对某些升级路径的支持。例如。您的应用程序已达到 v. 5.0，并且您已从 1.0、1.1、1.2、2.0、2.1 等升级脚本。您将它们汇总到 v4.0，然后您无法再升级以前的版本。解决方法是保留旧脚本作为升级的替代方案，或者如果您确定没有 4.0 之前版本的部署，请弃用该支持。
是的。好点，但当然，即使在卷起脚本之后，如果绝对需要，您也可以从 SCM 中取回原始展开的脚本。

【解决方案2】：

我认为从长远来看，它只会让事情变得更加复杂。整个版本需要存在于单个脚本中，以便您可以在一个上下文中测试该脚本并知道它可以在另一个上下文（如生产环境）中正常工作。

【讨论】：

好点。这是另一件可能会破坏的事情，或者至少需要进行测试。就一个脚本而言，有一些工具能够获取脚本文件夹并生成（一个文件）迁移脚本（到任何目的地），所以这一点是没有实际意义的，但正如你所说，这那时不会进行测试。另一方面，我们在迁移期间从不对生产进行初始创建...
您是说，对您而言，初始创建和升级是并行路径？

【解决方案3】：

马丁，

如果您在现实世界中，那么您的生产数据库只接受更新 - 您永远不会从头开始“创建”它。所以对你来说最重要的是存储、观看、审查等是更新脚本集。这些是可以投入生产的脚本，所以只有这些才是真正重要的。

将它们设为主要是正确的做法。但是开发人员需要能够获得模式的“当前图片”。 DBA 也喜欢这样做，尽管他们（太）经常通过登录生产服务器并启动某种 gui 工具来做到这一点。（哎呀！）

我对您的方法的唯一保留是当前/以前的架构按对象类型。这些脚本应该通过转储数据库本身自动生成。如果您可以按类型自动对它们进行分类，那就太好了！如果没有，尽你所能使它们易于导航，但指导规则应始终“从实时数据库自动生成”。

【讨论】：