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

StackOverflow https://stackoverflow.com/questions/2503696

题

我已经制定了数据库变更管理工作流程。它基于 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
        ...
    ...

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

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

优点是：

  • 对于开发和源代码控制，我们将采用与我们习惯的相同的每个文件对象设置
  • 对于部署，我们可以通过运行“初始+迁移”或运行“当前/”中的脚本将新的数据库实例启动到最新版本。
  • 对于开发人员来说，我们不需要运行数据库实例来进行开发。我们可以对Current/文件夹进行“离线”开发。

缺点是：

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

预先感谢您的任何意见！

有帮助吗？

解决方案

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

最大的缺点是缺乏权威的 .sql 文件，太难找到 当前的 任何对象（过程、表、视图等）的版本。但能够部署应用程序的优势在于 任何 以前的版本，以及通过良好控制和测试进行部署的优势 脚本 远远超过缺点。

如果您对使用此部署过程（部署 v1.0 的脚本）感到不好。然后应用 v1.1，然后 v1.2 ...直到最后应用 v4.5（当前版本），然后记住这一点：SQL Server 在内部使用完全相同的过程在版本之间升级数据库。当您附加较旧的数据库时，您会看到著名的“数据库正在运行从版本 611 到 612 的升级”，并且您会看到升级正在进行 一步步, ，不会直接升级到当前版本 651（或您的情况下的当前版本）。升级也不会运行 diff 工具来部署 v 651 而非 v.611.那是因为 最好的 方法就是你刚刚使用的方法，一步一步升级。

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

其他提示

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

马丁，

如果您在现实世界中，那么您的生产数据库仅接受更新 - 您永远不会从头开始“创建”它。所以对你来说最重要的是存储、观看、回顾等。是一组更新脚本。这些是将其投入制作的脚本，因此这些是唯一真正重要的脚本。

通过将它们作为主要内容，您正在做正确的事情。但开发人员需要能够了解架构的“当前情况”。DBA 也喜欢这样做，尽管他们（太）频繁地通过登录生产服务器并启动某种 GUI 工具来做到这一点。（哎呀！）

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top