我有一个数据库(SQL Server 2008 R2)，它主要受源代码控制(因此每个数据库对象一个文件，分组在文件夹中，例如表、 View 、存储过程)。目前，更改是通过编写 SQL 升级脚本进行的，然后使用一些自制批处理文件来执行它们(而且它们也很容易出错)。
因此，我们正在研究迁移是否对我们有用，但我还没有看到最佳实践的良好解释。大多数博客文章似乎假设一个空数据库，然后添加几个迁移(通常是 CreateUsers 和 CreateRoles)，但没有显示之后会发生什么？ 如果您有数百个存储过程，您是否希望将它们(就像我们目前拥有的那样)放在每个对象的 .sql 文件中，然后让您的迁移引用这些文件？我们是否混淆了基于状态的部署和基于迁移的部署？
换句话说，如果我们要进行迁移，我们是否应该有一个 SQL 文件来在某个已知状态(快照 #1)(包含数百个表和数百个存储过程)创建整个数据库，编写一个在一个主要项目的过程中进行大量迁移，然后在该项目结束时创建一个新快照并将其添加到源代码管理中？那么我们的 VCS 中唯一的就是快照以及在快照之间移动的迁移？但是，你如何追溯例如的历史？用户表，如果您没有版本控制下的各个对象？
最佳答案
您可能对 ReadyRoll 采取的方法感兴趣(商业)或 Flyway (开源)。全面披露:我在 Redgate 工作，他们制作了 ReadyRoll。
这些都是工具/框架，可以帮助您组织迁移脚本并为您减少大量跑腿工作。例如，决定进行更新时运行哪些脚本。
ReadyRoll 是一种混合方法。
它通过源控制这些对象的“状态”来专门解决大量存储过程(或其他可编程对象)更改的问题。例如只是将最后一个版本控制为删除/创建。对于表更改，它将在迁移文件夹中存储更改脚本的数字序列。
这样您就有了每个对象的历史记录，它会自动创建每个对象的创建脚本并将其存储为“架构模型”。因此，您可以查看 VCS 历史记录并了解对象如何随时间变化。
有一个很好的series of blog posts Vladimer Khorikov 介绍了版本控制数据库的不同技术。
关于sql-server - VCS 中具有迁移的数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37716044/