我试图找出在SQL中更改版本的最佳方法。 我知道有像Redgate和微软的SSDT这样的产品，但同样我想知道如果一个更手动的过程可能会使自动化部署变得更容易。控制DDL更改的版本
我有以下要求
如果我使用Redgate或SSDT，是否需要从数据库的当前状态生成部署脚本？
目前我想知道是否将更改脚本和syncronised创建脚本放入git/svn会是最简单的方式来实现此目的。但是，两人不同步的可能性让我感到不安。
在源代码控制中保留更改脚本是一件痛苦的事情，因为要回到特定时间点，需要运行基本创建，然后运行所有更改脚本+必须编写手动回滚脚本（如果需要）
编写手册更改脚本也是一个痛苦，因为你必须真正写脚本，以及这是2015年，所以不要这样做！
所以我真的推荐使用SSDT或redgate，redgate很酷，但SSDT是免费的，还包括设计时检查和重构，所以如果你做一些像SSDT中重命名表一样的东西，它会生成一个sp_rename而不是删除第一张桌子，并创建一个新的（这是什么红门工具将做什么）
无论你使用的是命令行版本的工具来做一个比较/部署时，你真的想要释放，所以只需要检查代码显示您在发布时希望数据库处于的状态。
对于你的要求，无论是展鹏和SSDT会做所有三个（除号被具有数据库在源代码控制创建语句所代表的照顾3）
你不提的唯一事情是静态或参考数据来处理这个问题，要么使用redgate数据比较工具，要么你可能会使用redgate源代码控制ssms加载项，如果你不打算使用ssdt来让你将表链接到csv文件。
如果您打算使用SSDT，那么请使用后期部署脚本，并为您需要在源代码管理中存储的每个表格创建合并语句。
SSDT岩确实是前进的方向，任何人开发的T-SQL代码（即使他们没有认识到这一点！）
埃德
如何在部署过程中处理数据迁移？如果我需要添加表/列，然后运行查询来填充新的工件，然后删除旧的列和旧的表，是否可以自动执行这种工作流程？我问得太多了吗？：P –
如果你有一个复杂的变化，那么你最好创建一个手动脚本 - 把它放在项目的post deploy脚本中，并且把它包装在一个IF EXIST中，就像旧表中的所有列一样），这样该脚本可以重新运行，当它已经部署到所有环境时，您可以根据需要将其删除。要获得这种状态随着时间的推移，你可以做的是创建你的新表，将数据插入新表中，然后在应用程序代码部署到所有环境后删除旧表。 –
我应该有想到了！作为两个单独的部署来做，很有意义，谢谢！ –