【问题标题】:Complex data migration in the Data-tier Application Framework (DAC Fx)数据层应用程序框架 (DAC Fx) 中的复杂数据迁移
【发布时间】:2012-03-19 21:46:33
【问题描述】:

我很高兴能够使用 DAC Fx 和声明式数据库开发。对我来说主要的障碍是如何处理跨多个不同版本的模式的复杂数据迁移。在旧世界中,我们可以简单地按顺序运行我们所有的升级脚本,这可以保证架构在数据迁移时处于正确的状态。当升级路径是动态的时,这是如何工作的?

例如,假设现有实例上有多个版本的架构 (DACPAC1-4):

  • DACPAC1:tableA 存在并且有有价值的客户数据
  • DACPAC2:tableA 已弃用并由 tableB 和规范化 tableC 替换;添加新的 表D
    • 部署后脚本:将数据从表 A 移动到新表 B 和 表C;删除表A
  • DACPAC3:tableC 有一个新的可空列 X
    • 部署后脚本:根据 tableD 填充可为空的列
  • DACPAC4:tableC.columnX 不可为空

如果我需要能够支持将 DACPAC1-3 服务器升级到最新的 DACPAC4,我现在必须以足够聪明的方式编写我的部署前和部署后脚本,以检测目标上当前和正确的 DACPAC按顺序处理数据迁移步骤。此外,我不能简单地重复使用我最初编写的幼稚的部署后脚本,因为它们依赖于模式的中间版本。

提前感谢您的任何建议!

【问题讨论】:

    标签: data-migration data-tier-applications dac


    【解决方案1】:

    我通常会做以下事情:

    1. 创建一个包含名为 SchemaVersion 的属性的系统表。所有升级脚本都被编程为首先检查当前版本,然后决定是否执行其内容。执行后,它会将 SchemaVersion 设置为脚本中存储的最新版本。

    2. 我通常还包括另一个名为 MinAppVersion 的属性(与当前架构兼容的最低版本)。当应用程序尝试连接到数据库时,它会将其当前程序集版本与存储在数据库中的 MinAppVersion 进行比较。如果版本等于或高于 MinAppVersion 则建立连接,否则抛出异常。

    我希望这会有所帮助。亲切的问候,

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-10-27
      • 2013-05-27
      • 2019-06-24
      • 2019-05-02
      • 1970-01-01
      • 2014-07-08
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多