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文件部署的替代方案更好。我已经争论了一段时间的确切方法：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。

Answer 2

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

Answer 3

马丁，

如果您在现实世界中，那么您的生产数据库只接受更新 - 您永远不会从头开始“创建”它。因此，存储，观看，审阅等最重要的是更新脚本集。这些是生产的脚本，因此这些是真正重要的。

你做的是正确的事情，让他们成为主要的。但是开发人员需要能够获得模式的“当前图片”。 DBA也喜欢这样做，虽然（太）频繁地通过登录到生产服务器并启动某种gui工具来实现。（让人惊讶！）

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

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

3 个答案: