我们如何处理数据库表的源代码管理和自动部署(配置管理)。我在SQL Server环境中工作，编写拖放脚本并为存储过程/触发器/函数甚至作业创建文件非常容易。处理新数据库表的脚本编制也很容易。但是，如果以后要修改该表，则不必担心会丢失数据，而不必只是删除它并使用新字段重新创建它。有没有自动的方法来解决这个问题？更新新的更改表后，是否编写临时表并回填脚本？ (如果有很多数据，可能会很粗糙)

任何建议将不胜感激。

解决方案

它的变化取决于我们要如何处理现有数据以及架构更改的范围，但是即使在Management Studio中，在提交更改之前，我们也可以生成所有更改的脚本。

对于大量数据或者存在约束或者外键的数据，即使简单的ALTER操作也要花费大量时间。

有可用的工具可以开发架构，开发更改，对这些更改进行版本化，并可以比较版本之间的差异，甚至可以生成SQL以进行DDL更改。

例如，查看Embarcadero Change Manager和Embarcardero提供的其他产品。

我们可以自动创建初始创建脚本，但实际上，ALTER脚本确实需要根据具体情况进行手工编码，因为在实践中，我们需要在其中编写自定义内容。

无论如何，我们都需要某种方式为每次更改创建Apply和Rollback脚本，并需要有一个运行它们的安装程序脚本(当然还有一个将它们回滚的回滚)。这样的安装程序可能应该记住该模式所在的版本，并以正确的顺序运行所有必要的迁移。

在这里查看我的文章：

http://marksverbiage.blogspot.com/2008/07/versioning-your-schema.html

诸如Red-gate的SQL Compare之类的工具对于确保我们具有完整的脚本非常有用。我们仍然可能需要手动对其进行调整，以确保以正确的顺序编写对象的脚本。确保对触发器，约束等以及表编写脚本。通常，我们将要使用alter命令而不是drop and create，尤其是在表很大的情况下。

我们所有的表和函数以及存储的proc也都必须处于源代码控制之下，因此如果需要，我们可以返回到旧版本。此外，我们的dbas会定期删除未在Source COntrol中找到的任何内容，从而使开发人员避免忘记这样做。

当然，所有升级到生产环境的开发脚本都应首先在QA或者登台服务器上运行，以确保脚本在产品上运行之前可以正确运行(无需任何更改)。另外，还需要考虑在产品上运行的时间，我们不想将用户锁定，特别是在繁忙的时期，并且时间表明在星期五下午晚些时候将脚本加载到生产中通常不是一个好主意。

哦，忘了说了，在将架构更改加载到生产环境之前，请确保我们具有一组良好的数据库备份。安全胜过遗憾。