我们一直在使用Visual Studio数据库项目来维护项目的当前架构,这对于我们在将数据库架构引入新开发机器方面效果很好,但我们还没有用它来升级环境。以前我们使用迁移脚本将您从初始版本带到下一版本,依此类推,直到您处于当前版本,但现在我们希望利用数据库项目的强大功能。
我最近通过Barclay Hill
阅读了这两篇文章 Managing data motion during your deployments (Part 1)
Managing data motion during your deployments (Part 2)
其中介绍了从一个版本到另一个版本的部署脚本的前后部署,我们已经习惯了很好的效果但是我现在陷入了一些我无法解决的问题,并且觉得我错过了。我们有两个不同版本的数据库,但迁移脚本不适用于两者中的较旧版本。以下是我们方案的简化版本。
表1
ColumnABC CHAR(1)
表1
ColumnXYZ INT
从版本1到版本2的数据动作
预部署脚本会检查数据库所处的版本,如果版本为1,则会将ColumnABC中的数据放入临时表中。
部署后脚本检查我们现在是否为版本2并检查是否存在在预部署脚本中创建的临时表,并在将char转换为int后将其放入新列ColumnXYZ中。
表1
Column123 INT
当我们将数据库从版本1升级到版本2然后升级到版本3时,一切正常。但是,如果我们在版本1上有一个数据库并希望跳转到版本3,则部署后脚本会失败,因为没有ColumnXYZ,因为它现在是Column123。
在旧的迁移方法中,这不会是一个问题,因为部署逐个遍历每个版本,但这不是数据库项目的工作方式。还有其他人经历过这个吗?你是如何处理的,我错过了一些明显的东西?
答案 0 :(得分:0)
很抱歉看到你在这里没有得到任何答案。你最终设法解决了什么问题吗?
我刚刚开始研究'数据花花公子',整个数据动作肯定似乎是房间里的大象。
我刚刚阅读了你提到的两篇博文,我的理解是你需要结合检查版本和预期的架构条件。所以我猜这意味着你需要在版本3的部署后脚本中执行两个不同的子句。
(请让我知道。我仍然在尝试决定是否投资这个或只是去经典的DIY路线。)
答案 1 :(得分:0)
在我看来,你至少有两个选择:
1)需要升级路径1-> 2-> 3.
2)将ColumnABC-ColumnXYZ数据运动更改为以下内容: