Visual Studio数据库项目用dacpac变更架构时如何保留数据

你遇到的是VS数据库项目（底层基于SSDT）默认部署顺序的典型卡点：pre-deploy脚本执行在所有架构变更之前，此时新表还未创建无法写入；post-deploy脚本执行在所有架构变更完成之后，此时旧表待删除字段已经被移除，无法读取历史数据。两种可直接落地的方案如下，全程不脱离dacpac版本控制流程，不会丢失历史数据。

方案一：分阶段发布（生产环境优先推荐，风险最低） #

该方案把一次大的架构拆成三次向后兼容的小变更发布，每一步都可以单独校验数据，不会出现发布死区：

• 第一次发布：仅新增目标表，保留旧字段
  在VS项目中新建Matter表的完整定义，字段按需求配置：MatterID（主键，建议设为自增IDENTITY字段）、ClaimID（外键关联Claims表的ClaimID字段）、ClaimantName、ClaimantNI、ClaimantAddress。注意此时不要删除Claims表中原有三个索赔人相关字段，也不要把Claims表重命名为Claim。
  生成dacpac发布到生产后，库内会同时存在带全部旧字段的Claims表、空的Matter表，现有业务完全不受影响。
• 第二次发布：同步历史数据
  在项目的post-deploy脚本中追加幂等的数据迁移逻辑，避免重复发布时插入重复数据：

  -- 仅同步尚未迁移到Matter表的历史数据
  INSERT INTO Matter (ClaimID, ClaimantName, ClaimantNI, ClaimantAddress)
  SELECT c.ClaimID, c.ClaimantName, c.ClaimantNI, c.ClaimantAddress
  FROM Claims c
  LEFT JOIN Matter m ON c.ClaimID = m.ClaimID
  WHERE m.MatterID IS NULL
  

  发布完成后，校验Claims表和Matter表的数据一致性，确认所有历史索赔人数据都已正确同步。
• 第三次发布：清理冗余架构
  数据校验通过后，在VS项目中删除Claims表的ClaimantName、ClaimantNI、ClaimantAddress三个冗余字段；如果需要将表名从Claims改为目标的Claim，直接使用VS数据库项目的「重构-重命名」功能操作，不要手动删除表重建，工具会自动生成安全的重命名脚本不会丢失数据。
  这次发布完成后，库结构就和目标架构完全一致，且历史数据无丢失。

方案二：单发布流程完成（适合测试/预发环境，或变更窗口紧张的场景） #

如果不想分三次发布，可以利用SQL Server临时表的会话级可见特性，绕开pre/post脚本的执行顺序死区，单个dacpac即可完成全流程变更：

1. 先在VS项目中直接定义好最终的目标架构：新建Matter表、删除Claims表的三个冗余字段、按需重命名Claims为Claim。
2. 在pre-deploy脚本中添加临时备份逻辑，在架构变更执行前把待迁移的历史数据存到会话临时表中：

   -- 提前备份待迁移的索赔人数据，临时表在整个dacpac发布会话内全程可见
   IF OBJECT_ID('tempdb..#TempClaimantBackup') IS NOT NULL
       DROP TABLE #TempClaimantBackup;
   
   SELECT ClaimID, ClaimantName, ClaimantNI, ClaimantAddress
   INTO #TempClaimantBackup
   FROM Claims
   WHERE ClaimantName IS NOT NULL;
   

3. 在post-deploy脚本中添加数据恢复逻辑，等架构变更完成、新Matter表创建完成后，把临时表中备份的历史数据插入到Matter表中：

   -- 从临时表迁移历史数据到新的Matter表
   INSERT INTO Matter (ClaimID, ClaimantName, ClaimantNI, ClaimantAddress)
   SELECT ClaimID, ClaimantName, ClaimantNI, ClaimantAddress
   FROM #TempClaimantBackup;
   
   -- 迁移完成后清理临时表
   DROP TABLE #TempClaimantBackup;
   

注意：dacpac发布过程中，pre-deploy脚本执行、架构变更部署、post-deploy脚本执行三个阶段复用同一个数据库连接会话，因此会话级临时表不会在流程中间被销毁，可以正常跨阶段读取数据。

发布注意事项 #

• 所有数据迁移脚本必须加幂等判断，避免重复发布时出现重复插入、主键冲突问题。
• 生产环境发布前，必须用生产库的全量备份在预发环境做一次完整的发布演练，校验数据迁移的完整性。
• 如果Matter表的外键约束设置了WITH CHECK，建议在数据迁移完成后再启用约束校验，避免迁移过程中出现约束报错。

内容的提问来源于stack exchange，提问作者variable