使用
使用部署后脚本更改表架构是否存在任何问题\潜在问题？
我的公司有一个Web应用程序（App A），其后端数据库具有使用CDC Replication复制到另一个公司应用程序的数据库（App B）的表。对这些表进行架构更改会导致SSDT在生成部署脚本时使用DROP / CREATE。对于在这些表上使用CDC Replication的App B数据库来说，这是一个问题，因为当删除并重新创建表时，App B的数据库的CT_ [table_name]表将被删除，从而带来App B下来。我的解决方案是使用部署后脚本对这些表进行ALTERATION，而不是允许SSDT生成DROP / CREATE。这种方法有任何潜在的问题或问题吗？
我真的可以使用一些帮助。
答案 0 :(得分：2)
如果您要从SSDT项目模型中排除这些表，则可以设想使用部署后脚本处理此类表更改。这可以通过以下任一方式实现：
Build Action属性设置为无 这会阻止SSDT尝试对该表执行任何操作，因此您不必担心比较引擎会产生破坏CDC实例的脚本。
当然，这意味着依赖于排除的表对象（例如proc或视图）的任何对象也需要移动到Post-Deployment脚本。这将导致数据库的可跟踪性降低，因为所有排除这些表将不再存储在源代码管理中的每个文件历史记录。
即使可以找到不会导致这些缺点的解决方案，例如根据Ed的优秀博客帖子使用预比较脚本，也需要考虑部署原子性的问题。如果部署部署发生在SSDT生成的脚本中，而另一部分发生在部署后脚本中，则可能会发生使数据库处于半部署状态的错误。这是因为SSDT仅对其负责的部署部分使用事务;在提交初始事务后，将执行部署后脚本中包含的任何内容。
这意味着您的部署后脚本需要以幂等方式编写，以便在出现问题时可以重新执行（对不起，如果这是一个明显的声明。 ..每当提到部署后脚本时，它似乎总是很有意义！）。
如果需要更高程度地控制表更改的部署方式，而不会丢失可跟踪性或部署原子性，那么我可以建议考虑迁移驱动的部署工具，如ReadyRoll （免责声明：我为Redgate Software工作）。 ReadyRoll是SSDT的项目子类型，但使用与SSDT完全不同的部署风格：不是等到部署才发现将删除/重新创建表，而是在开发时生成迁移脚本，允许更改同步在将其提交给源代码控制之前要进行的操作。
有关SSDT和ReadyRoll如何比较的更多信息，请查看ReadyRoll常见问题解答： http://www.red-gate.com/library/readyroll-frequently-asked-questions-faq
答案 1 :(得分：1)
您是否使用内置重构支持来重命名列/表？如果这样做，那么部署应该生成一个sp_rename。
如果你是，因为cdc是
的错误有关详细信息，请参阅https://the.agilesql.club/Blog/Ed-Elliott/Pre-Compare-and-Pre-Deploy-Scripts-In-SSDT。
版