2

我有一个数据库（SQL Server 2008 R2），它主要受源代码控制（因此每个数据库对象一个文件，在文件夹中组合在一起，例如表、视图、存储过程）。目前，更改是通过编写 SQL 升级脚本进行的，然后是一些自制批处理文件来执行它们（它们也很容易出错）。

因此，我们正在研究迁移是否对我们有用，但我还没有看到对最佳实践的很好解释。大多数博客文章似乎都假设一个空数据库，然后进行几次迁移（通常是 CreateUsers 和 CreateRoles），但没有显示之后会发生什么？如果您有数百个存储过程，您是否希望它们（就像我们目前拥有的那样）在每个对象的 .sql 文件中，然后让您的迁移引用这些文件？我们是否混淆了基于状态的部署和基于迁移的部署？

换句话说，如果我们要进行迁移，我们是否应该有一个 SQL 文件来创建处于某个已知状态的整个数据库（快照 #1）（包含数百个表和数百个存储过程），编写一大堆在一个主要项目的过程中进行迁移，然后在该项目结束时，创建一个新快照，并将其添加到源代码控制中？所以我们的 VCS 中唯一的东西就是快照，以及在快照之间移动我们的迁移？但是，如果您没有单独的对象在版本控制之下，您如何跟踪例如用户表的历史？

4

1 回答 1

4

您可能对ReadyRoll（商业）或Flyway （开源）采用的方法感兴趣。全面披露：我为制作 ReadyRoll 的 Redgate 工作。

这些都是工具/框架，可以帮助您组织迁移脚本并为您省去很多繁琐的工作。例如，决定在您进行更新时运行哪些脚本。

ReadyRoll 是一种混合方法。

它通过源控制这些对象的“状态”来专门解决大量存储过程（或其他可编程对象）更改的问题。例如，仅将最后一个版本版本控制为删除/创建。对于表更改，它将更改脚本的数字序列存储在迁移文件夹中。

因此，您拥有每个对象的历史记录，它会自动创建每个对象的创建脚本并将其存储为“模式模型”。因此，您可以查看您的 VCS 历史记录，了解对象随时间的变化情况。

Vladimer Khorikov 有一系列关于版本控制数据库的不同技术的博客文章。

于 2016-06-10T08:44:19.767 回答